Как Citadel структурирует свои данные, используя только хранилище ключей/значений BerkeleyDB?

Я читал документацию Citadel, и она упомянул, что для хранения данных используется BerkeleyDB. Поскольку BerkeleyDB является хранилищем ключей/значений, мне интересно, как они могут управлять всеми отношениями данных (поскольку Citadel делает много вещей), используя такую ​​простую модель данных.

CREATE TABLE citadel (
  key LONGBLOB INDEX,
  data LONGBLOB
);

Это дает мне шанс, наконец, увидеть полноценное приложение, смоделированное с использованием базы данных NoSQL. Тем не менее, я не смог найти никакой документации о том, как они это делают.

Итак, как Citadel структурирует свои данные, используя только хранилище ключей и значений BerkeleyDB?

  • Как он сопоставляет электронные письма с пользователями?
  • Как пользователи связаны с другими пользователями?
  • Как хранятся контакты?
  • Как найти похожие ответы по электронной почте?
  • Как письма помечаются как просмотренные?

и этот список можно продолжать и продолжать...


nosql database-design key-value berkeley-db
person Xeoncross    schedule 10.09.2012    source источник
comment
@Charles, эта ссылка выше указывает на citadel.org. Я также только что связал слово Citadel.   -  person Xeoncross    schedule 10.09.2012

Ответы (2)


arrow_upward
2
arrow_downward

Довольно много баз данных NoSQL в чистом виде сравнимы с файловыми системами. Имея ключ (=путь), вы получаете блок данных (=содержимое файла). Остальное примерно сводится к настройке и дополнительным функциям;

  • Множество (миллиарды и миллиарды) ключей в одном пространстве имен? (HBase, Riak, BerkeleyDB, ...)
  • Поддержка значений нескольких ТБ? (Amazon S3) Или настроен для множества мелких (Zookeeper)
  • Непрозрачные значения? Одни базы данных не смотрят на них (HBase, BerkeleyDB), другие смотрят (CouchDB).

В настоящее время кажется, что наиболее популярным является сканирование ключей (HBase, Cassandra, CouchDB и, я думаю, BerkeleyDB), когда вы запрашиваете интересующий вас интервал ключей, например. «От foo@bar:emails:folderName:00000000 до foo@bar:emails:folderName:999999999». Обычно это возвращает список ключей и/или значений, которые находятся в интервале ASCIIbetic между ними. Таким образом, вы можете эмулировать файловую иерархию в плоском пространстве имен.

Следующая проблема — параллелизм. Очень коротко: большинство баз данных NoSQL отказываются от ACID в пользу масштабируемости и/или доступности. Дополнительные сведения см. в Теореме CAP.

В общем, очень сложно отдать должное предмету за такой короткий промежуток времени, поэтому я очень рекомендую вам изучить его самостоятельно.

Выберите какой-нибудь проект с открытым исходным кодом (OpenTSDB делает вещи интересным, но очевидным образом). Или соберите что-нибудь на NoSQL сами.

person Morten Siebuhr    schedule 19.12.2012
comment
Да, меня в основном интересуют такие вещи, как ваш key:0 to key:999 пример. Получение диапазона ключей — интересная идея. Такие системы, как Redis, также поддерживают карты, хэши и списки. Еще один пример практического использования пары «ключ-значение» — создание двух значений для каждой учетной записи пользователя, таких как user:99 => [email protected] и user:[email protected] => 99, чтобы вы могли находить пользователей по идентификатору или электронной почте (в реальной жизни их было бы гораздо больше). По сути, мне просто любопытно, как Citadel моделирует сложные отношения, такие как все электронные письма от данного пользователя, с помощью такого простого хранилища. - person Xeoncross; 19.12.2012

arrow_upward
1
arrow_downward

Некоторое время назад я разобрался с Amazon Simple DB и подозреваю, что BerkleyDB делает то же самое.

И ключ, и значение являются BLOBS. По сути, там можно хранить что угодно. Давайте возьмем пример, основанный на некоторых ваших перечисленных пунктах/вопросах.

Пункты, которые я затрону, следующие:

  • Как он сопоставляет электронные письма с пользователями?
  • Как пользователи связаны с другими пользователями?

Как и в реляционных базах данных, значение ключа должно быть уникальным, поэтому давайте предположим, что идентификатор пользователя/имя пользователя уникальны. Таким образом, мы можем иметь ключевое значение, такое как admin, jdoe, serviceadmin и т. д., в качестве ключей. Поскольку мы можем хранить что угодно в поле значения, мы можем сохранить, например, XML-документ в поле значения.

Пример может выглядеть так:

Key:
    admin
Value:
     <user>
           <emaillist>
                <email>[email protected]</email>
           </emaillist>
           <relatedusers>
                 <relateduser>
                          <name>jdoe</name>
                          <relationship>someidentifier</relationship>
                 </relateduser>
                 <relateduser>
                          <name>serviceadmin</name>
                          <relationship>someidentifier</relationship>
                 </relateduser>
           </relatedusers>
      </user>

Поскольку XML можно использовать для описания данных различными способами, это, вероятно, очень простой пример того, чего можно достичь. Однако вы можете хранить там некоторый двоичный формат данных, который очень похож на XML, который вы можете каким-то образом извлекать и интерпретировать. Как и бит 1, это активное состояние пользователя и т. д.

Сила NoSQL в том, что он может хранить что угодно, и структура от строки к строке тоже может быть разной. Это тоже обратная сторона. Поскольку невозможно интерпретировать данные без надлежащей документации, такие базы данных трудно понять с точки зрения структуры. Они могут содержать буквально все что угодно.

Надеюсь, теперь это имеет какой-то смысл.

person Namphibian    schedule 19.12.2012