Как хранить 15 х 100 миллионов 32-байтовых записей для последовательного доступа?

Question

Я получил 15 х 100 миллионов 32-байтовых записей. Необходим только последовательный доступ и добавления. Ключ длинный. Значение является кортежем (Дата, Двойной, Двойной). Есть ли в этой вселенной что-то, что может это сделать? Я готов иметь 15 отдельных баз данных (sql / nosql) или файлы для каждой из этих 100 миллионов записей. У меня только ядро ​​i7, 8 ГБ оперативной памяти и 2 ТБ жесткого диска.

Я пробовал PostgreSQL, MySQL, Kyoto Cabinet (с тонкой настройкой) с кодировкой Protostuff.

БД SQL (с индексами) делают самый глупый запрос вечно.

B-Tree кабинета Киото может обрабатывать до 15-18 миллионов записей, после чего добавление может длиться вечно.

Я так сыт по горло, что думаю о том, чтобы вернуться к awk + CSV, который, как я помню, раньше работал для данных такого типа.

Answer 1

Если ваш сценарий означает, что всегда последовательно просматривает все записи, использование базы данных может быть излишним.Если вы начнете нуждаться в случайном поиске, замене / удалении записей или проверке, не является ли новая запись дубликатом старой записи, ядро ​​базы данных будет иметь больше смысла.

Для последовательного доступа, пара текстовфайлы или созданные вручную двоичные файлы будут легче обрабатывать.Вы говорите как разработчик - я бы, вероятно, выбрал собственный двоичный формат и получил бы к нему доступ с помощью отображенных в памяти файлов, чтобы улучшить скорость последовательного чтения / добавления.Нет кеширования, просто скользящее окно для чтения данных.Я думаю, что он будет работать лучше и даже на обычном оборудовании, чем любая БД;Я сделал такой анализ данных один раз.Это также было бы быстрее, чем использование файлов CSV;тем не менее, я не уверен, сколько и если он удовлетворил усилия по разработке двоичного хранилища, прежде всего.

Как только база данных станет интересной, вы можете взглянуть на MongoDB и CouchDB .Они используются для хранения и обслуживания очень больших объемов данных.(Существует лестная оценка , которая сравнивает одну из них с традиционными БД.).Базы данных обычно нуждаются в разумной аппаратной мощности, чтобы работать лучше;Может быть, вы могли бы проверить, как эти двое будут делать с вашими данными.

--- Ferda

Answer 2

Для последовательного чтения и записи leveldb будет очень хорошо обрабатывать ваш набор данных.

Answer 3

Ответ Фердинанда Прантля очень хороший.Два момента:

• По вашим требованиям я рекомендую вам создать очень жесткий двоичный формат.Это будет легко сделать, потому что ваши записи имеют фиксированный размер.
• Если вы хорошо понимаете свои данные, вы можете сжать их.Например, если ваш ключ является увеличивающимся значением журнала, вам не нужно хранить его полностью.Вместо этого сохраните разницу к предыдущему значению (которое почти всегда будет одним).Затем используйте стандартный алгоритм / библиотеку сжатия, чтобы сэкономить большой объем данных.

Answer 4

Я думаю, что это около 48 гигабайт данных в одной таблице.

Когда вы попадаете в большие базы данных, вы должны смотреть на вещи немного по-другому.С обычной базой данных (скажем, таблицами менее пары миллионов строк), вы можете сделать что угодно в качестве доказательства концепции.Даже если вы не знакомы с базами данных SQL, настройкой сервера и настройкой оборудования, ответ, который вы придумали, будет, вероятно, правильным.(Хотя иногда вы можете быть правы по неправильной причине.)

Обычно это не так для больших баз данных.

К сожалению, вы не можете просто выбросить 1,5 миллиарда строк прямо на ненастроенную PostgreSQLсервер, запустите пару запросов и скажите: «PostgreSQL не может справиться с этим».Большинство баз данных SQL имеют способы работы с большим количеством данных, и большинство людей не так много о них знают.

Вот некоторые вещи, о которых мне нужно подумать, когда мне приходится обрабатывать много данных в долгосрочной перспективе.(Краткосрочная или одноразовая обработка, обычно не стоит сильно заботиться о скорости. Многие компании не будут вкладывать средства в увеличение объема ОЗУ или дюжины высокоскоростных дисков - или даже нескольких SSD) - дажедолгосрочное решение, не говоря уже о разовой работе.)

• Процессор сервера.
• Оперативная память сервера.
• Диски сервера.
• Конфигурация RAID.(Возможно, стоит обратить внимание на RAID 3.)
• Выбор операционной системы.(64-разрядные против 32-разрядных, BSD против производных AT & T)
• Выбор СУБД.(Oracle обычно превосходит PostgreSQL, но это стоит.)
• Настройка СУБД.(Общие буферы, сортировка памяти, размер кэша и т. Д.)
• Выбор индекса и кластеризация.(Много разных видов в наше время.)
• Нормализация.(Вы будете удивлены, как часто 5NF превосходит более низкие NF. То же самое для натуральных ключей.)
• Табличные пространства.(Возможно, поместив индекс на свой собственный SSD.)
• Разметка.

Я уверен, что есть другие, но я еще не пил кофе.

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

Теперь, можете ли вы реализовать эти оптимизации, это другой вопрос- большинство компаний не будут вкладывать средства в новый 64-разрядный сервер под управлением Oracle и дюжину новейших жестких дисков «Я самый быстрый жесткий диск» для решения вашей проблемы.

Но кто-то собирается заплатить либо за оптимальное аппаратное и программное обеспечение, либо за опыт настройки dba, либо за время программиста и ожидание на неоптимальном оборудовании.Я видел такие проблемы, которые решались месяцами.Если на это уйдут месяцы, деньги на оборудование, вероятно, являются разумным вложением.