Эффективно хранение 7.300.000.000 строк

"Теперь - как Вы занялись бы описанной проблемой?"

С простыми плоскими файлами.

Вот то, почему

"все запросы будут сделаны на определенном entity_id. Т.е. получите все строки, описывающие entity_id = 12345".

у Вас есть 2 000 000 объектов. Раздел на основе числа объекта:

level1= entity/10000
level2= (entity/100)%100
level3= entity%100

каждый файл данных level1/level2/level3/batch_of_data

, можно тогда считать все файлы в данной части каталога для возврата образцов для обработки.

, Если кто-то хочет реляционную базу данных, затем загрузите файлы для данного entity_id в базу данных для их использования.

Редактирование На дневных числах.

1. date_id / entity_id правило уникальности не что-то, что должно быть обработано. Это (a) тривиально наложено на имена файлов и (b) не важно для запросов.

2. date_id "трансформация" ничего не означает - нет никакого запроса, таким образом, нет никакой потребности переименовать что-либо. Эти date_id должен просто вырасти без связанного с опорной даты. Если Вы хотите произвести чистку старых данных, то удалите старые файлы.

, Так как никакой запрос не полагается date_id, ничто никогда не должно делаться с ним. Это может быть имя файла для всего, что это имеет значение.

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

Редактирование на открывается/закрывает

For запись, необходимо оставить файл (файлы) открытым. Вы делаете периодические сбросы (или закройтесь/вновь откройте) гарантировать, что материал действительно идет в диск.

у Вас есть два варианта для архитектуры Вашего писателя.

1. Сделали, чтобы единственный "писатель" обработал, который консолидирует данные из различного источника (источников). Это полезно, если запросы являются относительно частыми. Вы платите за слияние данных во время записи.

2. Имеют несколько файлов, открытых одновременно для записи. При запросах, слияние эти файлы в единственный результат. Это полезно, запросы, относительно редки. Вы платите за слияние данных во время запроса.

Возможно, вы захотите взглянуть на эти вопросы:

Большой первичный ключ: 1+ миллиардов строк MySQL + InnoDB?

Большие таблицы MySQL

Лично я бы также подумал о расчете ширины вашей строки, чтобы дать вам представление о том, насколько большой будет ваша таблица (согласно примечанию о разделении в первой ссылке).

HTH.,

S

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

, Предполагают, что Ваши данные размечаются на диске как массив 2M записи фиксированной длины (один на объект) каждый содержащий 3 650 строк (один в день) 20 байтов (строка для одного объекта в день).

Ваш шаблон чтения читает один объект. Это непрерывно на диске, таким образом, это берет 1, ищут (о 8mllisecs) и читают 3650x20 = о 80K в, возможно, 100MB/sec..., таким образом, это сделано в части секунды, легко встретив Ваш шаблон чтения 1-query-per-second.

обновление должно записать 20 байтов в 2M различные места на диске. В самом простом случае это взяло бы 2M, ищет, каждый из которых сопровождает 8millisecs, таким образом, потребовалось бы 2M*8 мс = 4,5 часа. При распространении данных через 4 “raid0” диска, могло бы потребоваться 1,125 часа.

Однако места только 80K независимо. В, что означает, существует 200 таких мест в блоке 16 МБ (типичный размер дискового кэша), таким образом, он мог работать в чем-либо до 200 раз быстрее. (1 минута), Действительность где-нибудь между двумя.

Мой механизм устройства хранения данных воздействует на такую философию, хотя это - немного более общая цель, чем массив фиксированной длины.

Вы могли кодировать точно, что я описал. При помещении кода в MySQL, сменный механизм устройства хранения данных означает, что можно использовать MySQL для запросов данных с различными генераторами отчетов и т.д.

Между прочим, Вы могли устранить дату и идентификатор объекта от сохраненной строки (потому что они - индексы массива), и может быть уникальный идентификато𠆓, если Вам действительно не нужен он, так как (идентификатор объекта, дата) уникально, и сохраните 2 значения как 3-байтовый интервал Тогда, Ваша сохраненная строка составляет 6 байтов, и у Вас есть 700 обновлений на 16M и поэтому более быстрые вставки и меньший файл.

Редактирование Выдерживает сравнение с Плоскими файлами

, я замечаю, что комментирует общие плоские файлы пользы. Не забывайте, что каталоги являются просто индексами, реализованными файловой системой, и они обычно оптимизируются для относительно небольших чисел относительно больших объектов. Доступ к файлам обычно оптимизируется так, чтобы он ожидал относительно небольшое количество файлов быть открытым, и имел относительно высокие издержки для открытого и близкого, и для каждого файла, который открыт. Все те "относительно" относительно типичного использования базы данных.

Используя файловую систему называет как индекс для идентификатора объекта, который я беру, чтобы быть нередким целым числом, 1 - 2 миллиона парадоксальны. В программировании Вы использовали бы массив, не хеш-таблицу, например, и Вы неизбежно собираетесь подвергнуться большому количеству издержек для дорогого пути доступа, который мог просто быть массивом indeing операция.

Поэтому, если Вы используете плоские файлы, почему бы не использовать всего один плоский файл и индексировать его?

Редактирование на производительности

производительность этого приложения будет во власти времен поиска на диске. Вычисления, которые я сделал выше, определяют лучшее, которое можно сделать (хотя можно сделать, ВСТАВЛЯЮТ более быстрый путем замедления ВЫБОРА - Вы не можете сделать их обоих лучше). Не имеет значения, используете ли Вы базу данных, плоские файлы или один плоский файл, кроме [1 123], что можно добавить, больше ищет это, Вы действительно не нуждаетесь и замедляете его далее. Например, индексация (является ли это индексом файловой системы или индексом базы данных) вызывает дополнительный I/Os по сравнению с "массивом, ищут", и они замедлят Вас.