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

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

00000000001 : `12341234...12341234'

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

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

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

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

Какие-либо предложения?


xml json database data-storage
person jbranchaud    schedule 09.07.2011    source источник
comment
также время быстрого поиска -- как искать? По точному совпадению идентификатора? По точному соответствию bignumber? Частичным сопоставлением чего-либо?   -  person Programmer Bruce    schedule 09.07.2011

Ответы (4)


arrow_upward
4
arrow_downward

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

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

Использование чего-то вроде SQLite также будет иметь очень небольшие накладные расходы и позволит использовать удобные методы доступа.

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

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

person Thilo    schedule 09.07.2011
comment
Я хотел бы получить доступ к данным из веб-приложения, поэтому я хотел бы иметь данные на сервере. Смогу ли я сделать это с BerkeleyDB и SQLite? - person jbranchaud; 09.07.2011
comment
Да, так как ваш веб-сервер будет читать из файла (который является локальным с его точки зрения). Если вам нужно иметь более одного веб-сервера, перейдите на MySQL или Redis. - person Thilo; 09.07.2011
comment
Ваш ответ был очень полезен. Я думаю, что попробую SQLite из-за его простоты. Однако я буду помнить о BerkeleyDB. - person jbranchaud; 09.07.2011
comment
Я не смогу сохранить свое большое числовое значение (около 100 символов) как целое число. Целое число SQLite3 достигает только 8 байтов, поэтому я думаю, что следующий лучший вариант — сохранить его как текст. Однако я сделаю идентификатор целым числом. - person jbranchaud; 09.07.2011
comment
Вы можете использовать byte[] для больших данных. Более компактный, чем текст. - person Thilo; 09.07.2011

arrow_upward
3
arrow_downward

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

person gordy    schedule 09.07.2011
comment
Это предполагает, что сохраняемые числа имеют примерно одинаковую длину (так что заполнение не слишком расточительно) и что в последовательности идентификаторов не так много пробелов. Но тогда да, это было бы очень эффективно для хранения и доступа. - person Thilo; 09.07.2011

arrow_upward
1
arrow_downward

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

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

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

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

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

person Joshua Martell    schedule 09.07.2011

arrow_upward
0
arrow_downward

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

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

person StaxMan    schedule 09.07.2011