Верхний предел для количества строк в базах данных с открытым исходным кодом? - PullRequest
Новая
       9

Верхний предел для количества строк в базах данных с открытым исходным кодом?

3 голосов
/ 17 июля 2009

У меня есть проект, в котором я занимаюсь извлечением данных из большой базы данных. В настоящее время я храню все данные в текстовых файлах, и вместо этого пытаюсь понять затраты и преимущества хранения реляционной базы данных. Точки выглядят так: 

CREATE TABLE data (
    source1 CHAR(5),
    source2 CHAR(5),
    idx11   INT,
    idx12   INT,
    idx21   INT,
    idx22   INT,
    point1  FLOAT,
    point2  FLOAT
);

Сколько очков я могу получить при разумной производительности? У меня сейчас ~ 150 миллионов точек данных, и у меня, вероятно, не будет больше 300 миллионов. Предположим, что я использую коробку с 4 двухъядерными процессорами Xeon 2 ГГц и 8 ГБ оперативной памяти.

Ответы [ 3 ]

7 голосов
/ 17 июля 2009

PostgreSQL должен быть в состоянии вместить ваши данные - до 32 терабайт на таблицу и т. Д. И т. Д. Если я правильно понимаю, вы говорите о 5 ГБ в настоящее время, макс. 10 ГБ (о 36 байт / строка и до 300 миллионов строк), поэтому практически любая база данных должна легко вместить вас.

3 голосов
/ 17 июля 2009

К вашему сведению: Postgres масштабируется лучше, чем MySQL для многопроцессорных / перекрывающихся запросов, из обзора, который я читал несколько месяцев назад (извините, без ссылки).

Я предполагаю из вашего профиля, что это какая-то биометрическая (последовательность кодонов, последовательность фермента против аминокислотной последовательности белка или что-то подобное). Если вы собираетесь атаковать это с одновременными запросами, я бы пошел с Postgres.

OTOH, если данные будут загружаться один раз, а затем сканироваться одним потоком, возможно, MySQL в режиме «ACID не требуется» будет лучшим совпадением.

У вас есть кое-какие планы на случай использования вариантов доступа, прежде чем вы сможете выбрать «лучший» стек.

2 голосов
/ 17 июля 2009

MySQL более чем способен удовлетворить ваши потребности, а также предложить Алексу PostgreSQL. Добиться разумной производительности не составит труда, но если к таблице будет интенсивный доступ и большой объем DML, вам нужно будет узнать больше о блокировке, используемой базой данных, которую вы в итоге выберете.

Я считаю, что PostgreSQL может использовать блокировку на уровне строк из коробки, где MySQL будет зависеть от выбранного вами механизма хранения. MyISAM блокирует только на уровне таблицы, и, следовательно, страдает параллелизм, но механизмы хранения, такие как InnoDB для MySQL, могут и будут использовать блокировку на уровне строк для увеличения пропускной способности. Я бы предложил начать с MyISAM и перейти на InnoDB, только если вам нужна блокировка на уровне строк. MyISAM хорошо работает в большинстве ситуаций и чрезвычайно легок. У меня было более 1 миллиарда строк в MySQL с использованием MyISAM, и с хорошей индексацией и секционированием вы можете добиться высокой производительности. Вы можете прочитать больше о механизмах хранения в MySQL на MySQL Storage Engine и о разбиении таблицы на Разделение таблицы . Вот статья о разделах на практике в таблице из 113M строк , которая также может оказаться полезной.

Я думаю, что преимущества хранения данных в реляционной базе данных намного перевешивают затраты. Есть так много вещей, которые вы можете сделать, когда ваши данные находятся в базе данных. Восстановление на определенный момент времени, обеспечение целостности данных, более точный безопасный доступ, разделение данных, доступность для других приложений на общем языке. (SQL) и т. Д. И т. Д.

Удачи в вашем проекте.

...