Самый эффективный способ хранения миллионов простых данных?

Question

Мои данные выглядят так:

00000000001: `12341234 ... 12341234 '

В основном уникальное значение идентификатора, связанное с большой строкой чисел (менее 100 символов).

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

Я рассматривал БД с открытым исходным кодом как вариант (MySQL) и также рассматривал что-то вроде JSON или XML. Есть ли другие варианты? Что будет лучше?

Причина, по которой я не уверен, заключается в том, что данные так просты. Я боюсь использовать определенные базы данных, потому что некоторые из них являются реляционными или объектно-ориентированными, но у меня нет необходимости в этих функциях (здесь могут быть накладные расходы). Я также боюсь, что мои данные слишком просты и повторяются для чего-то вроде JSON, потому что я чувствую, что большая часть файлового пространства будет занята повторением "id" : и "bignumber" : снова и снова.

Есть предложения?

Answer 1

Я думаю, что наиболее эффективным способом хранения этих данных было бы опустить «id» и просто хранить ваши большие числа в фиксированном формате.Вам понадобится около 42 байтов для хранения чисел с 100 цифрами или менее, и вы можете легко найти нужный номер, умножив «id» на 42 и перейдя прямо к смещению, в котором хранится ваш номер.

Answer 2

Похоже, что id и value являются целочисленными значениями, поэтому их хранение в виде двоичных данных (в отличие от строк) сэкономит много места.Это исключает JSON или XML, которые основаны на тексте.

Я думаю, что вы хотите использовать хранилище значений ключей, такое как BerkeleyDB.Они позволяют осуществлять быстрый поиск по ключу (но не более того).

Использование чего-либо, подобного SQLite, также может привести к очень небольшим издержкам и позволит использовать удобные методы доступа.данные, не считывая их полностью в память в первую очередь (механизмы управления базами данных управляют этим для вас, с помощью JSON или ручного формата, это может быть много работы).

Если вам не нужен доступ к сети (но вы хотитедля работы с локальными файлами) лучше всего подойдет встроенная система баз данных, такая как BerkeleyDB или SQLite.Отсутствие сервера также значительно снижает накладные расходы на установку.

Answer 3

MySQL или аналогичный будет обрабатывать много деталей для вас.SQLite тоже может быть хорошим, так как вам не нужно так много возможностей.

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

Как подсказывает @gordy, если все ваши значения имеют много цифр, вы могли бы добиться большего с фиксированным размером строки для всего, так как поиск будет быстрее.Используйте переменную ширину, если размер важнее.

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

http://dev.mysql.com/doc/refman/5.1/en/archive-storage-engine.html

Answer 4

Любая старая база данных должна работать нормально;от BDB (или более современных вариантов, Redis, Tokyo Cabinet) до стандартных баз данных SQL, таких как MySQL или Postgres.Мой собственный фаворит для последнего - H2 , простая, но достаточно производительная и хорошо встраиваемая база данных SQL.

Для базовых вариантов хранения будет больше;XML / JSON (часто сжимается с помощью gzip) - это хорошо, но если вам нужен поиск по id, база данных имеет больше смысла.