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

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

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

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

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

Есть рекомендации? Кстати, я использую С#, поэтому предпочтительнее все, что связано с оболочками .NET.

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


person Groo    schedule 25.11.2010    source источник


Ответы (1)


Традиционные хранилища на основе 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 очень хорош в параллелизме, поэтому вы забудете о любых блокировках или чем-то еще.

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

person coffeesnake    schedule 25.11.2010
comment
Спасибо за предложение. На самом деле это не 10 тыс. записей по 200 КБ каждая, это около 10 тыс. измерений в секунду, но в двоичной форме каждая группа из 50 измерений может быть представлена ​​с помощью ~ 1 КБ, поэтому необработанные двоичные данные будут равняться всего 200 КБ в секунду. - person Groo; 26.11.2010