Простая структура хранения больших объемов данных - PullRequest
Новая
       25

Простая структура хранения больших объемов данных

3 голосов
/ 25 ноября 2010

Существует ли инфраструктура ACID для хранения больших объемов данных, которая также позволила бы некоторые базовые возможности поиска? Я не ищу полноценную СУБД, а скорее что-то быстрое, легкое и простое. Даже то, что просто позаботится об атомных фиксациях, было бы замечательно, просто чтобы не изобретать это заново в случае сбоя питания.

SQL Server слишком медленный для этого и имеет слишком много накладных расходов, SQLite еще медленнее (с потенциально меньшими издержками?).

По сути, мне нужно хранить большое количество данных с метками времени каждую секунду. Как нормализованные данные, это будет соответствовать ~ 10 тыс. Строк таблицы, но как двоичные данные они могут быть представлены с использованием ~ 200 тыс. КБ. Очевидно, что запись 200 КБ на диск - это просто, по сравнению с записью 10 КБ строк в реляционную базу данных.

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

Есть какие-нибудь рекомендации? Я использую C # btw, поэтому все, что с оболочками .NET будет предпочтительным.

[Изменить] Что касается ACID, я только что нашел это, например: Управляемая оболочка для транзакционной NTFS (хотя TxF - это «Vista и более поздние версии») функция).

1 Ответ

1 голос
/ 25 ноября 2010

Традиционные хранилища на основе SQL будут предоставлять ACID, однако массовое обновление многих будет медленным. С другой стороны, NoSQL-решения / хранилища значений ключей обычно не предоставляют вам надежные транзакции или какой-либо способ плавного индексирования для быстрого поиска с помощью чего-то еще, кроме одного ключа. Поэтому нам нужно что-то, что объединяет преимущества обоих подходов.

Я хотел бы рассмотреть возможность использования CouchDB (NoSQL-карта / уменьшить базу данных на основе документов с RESTful API) и принять следующую стратегию: CouchDB не имеет транзакций с точки зрения атомарного сохранения нескольких документов, однако, когда речь идет о сохранении одного документа - он сверхнадежен и атомарен, а также позволяет управлять несколькими версиями одновременно.

Таким образом, если у вас есть 10000 записей данных размером ~ 200-300 кБ каждая, вы можете сохранить их как один документ. Это может показаться странным для вас, но дело в том, что вы можете создавать представления поверх коллекций документов, которые на самом деле являются инкрементными индексами. И один документ может дать несколько результатов просмотра. Представления пишутся в javascript (который оценивается только один раз при создании / обновлении документа), поэтому вы можете индексировать их по своему желанию - по ключевым словам, числовым значениям, датам - практически все, что вы можете сделать с помощью javascript. Получение результатов просмотра происходит очень быстро, потому что они предварительно проиндексированы в дереве B +.

Преимущества этого подхода:

  • CouchDB использует JSON поверх HTTP в качестве протокола передачи данных, поэтому вы можете использовать любой HTTP-клиент или REST-клиент или встроенную оболочку C # (их несколько)
  • Ваша массовая вставка этого документа объемом 200 КБ будет атомарной и займет один HTTP-запрос
  • Ваша вставка будет асинхронной, потому что это всего лишь HTTP.
  • У вас будет MVCC - CouchDB очень хорошо справляется с параллелизмом, поэтому вы забудете о любых блокировках или чём-либо.

Просто дайте ему шанс - это сэкономило мне кучу времени.

...