Эффективный способ хранения и поиска полиномов (числовых массивов)

У меня есть огромное количество полиномов степени 6 (например, x^6 + 2*x^5 + x^4 + x^3 + x^2 + 1), хранящихся в текстовых файлах вместе с некоторой дополнительной информацией. Общая сумма больше 400 000 000. Все они имеют целые коэффициенты.

Я хотел бы эффективно хранить их, а затем выполнять быстрый поиск некоторого полинома в моем магазине. Мне не нужна функциональность множественных клиентов. Я хотел бы хранить данные и работать с ними на одной машине.

Мне кажется, это классические задачи БД. Итак, теперь я рассматриваю некоторую БД в качестве двигателя для этого.

  1. Какая БД наиболее эффективна в моем случае? Достаточно ли эффективен sqlite?
  2. Что, если это самый эффективный способ хранения многочленов? Таблица со столбцами a0, a1, a2 ... a6, add_info или какая-то сериализация, например сериализация строк "5,3,5,6,1,2,3", или может быть какая-то БД имеет тип данных массива? Я собираюсь сделать не только поиск с точным соответствием, но что-то вроде этого get all polynomials with a6 = 3 или get all uniq a5 for polynomials with a6 = 3.

arrays sql database sqlite polynomials
person petRUShka    schedule 30.07.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Вероятно, вы захотите использовать более мощную базу данных, чем SQLite, для 400 миллионов строк. Существуют бесплатные версии MySQL, Postgres, SQL Server и Oracle (например), которые могут работать лучше. Обратите внимание, что Stack Overflow не является сайтом для рекомендаций конкретных продуктов. Я просто поднял это в ответ на ваш конкретный вопрос о SQLite. И SQLite может подойти для этой цели.

Ваша базовая структура данных будет полиномиальным идентификатором вместе с 7 столбцами целых чисел, по одному для каждого коэффициента.

Основываясь на ваших примерах запросов, вам понадобится отдельный индекс для каждого коэффициента. Например:

create index idx_polynomials on polynomials(a6);

Вы не хотели бы сериализовать значения. Это устранило бы большую часть полезности хранения этих данных в реляционной базе данных и предотвратило бы использование индексов.

person Gordon Linoff    schedule 30.07.2014
comment
что посоветуете вместо SQLite? Mysql или Postgres для такого типа задач хранения и поиска? - person petRUShka; 30.07.2014
comment
Что конкретно делает SQLite неподходящим для этого? Основные отличия SQLite заключаются во внедрении и отсутствии параллелизма, ни одно из которых не должно влиять на это. - person CL.; 30.07.2014
comment
@КЛ. . . . Насколько мне известно, SQLite не поддерживает параллелизм в запросах, разделение данных и, возможно, другие расширенные возможности. Начиная с таблицы с 400 миллионами строк, я хотел бы оставить открытыми варианты повышения производительности, даже если это потребует дополнительных затрат на поддержку. Однако при соответствующей архитектуре физической машины SQLite вполне может справиться с этой задачей достаточно хорошо. - person Gordon Linoff; 30.07.2014