DocumentDB vs Key-Value DB с иерархией Производительность

Question

Прежде всего: я знаю, что DB Key-Value лучше всего работают с исполняемыми базами данных. Мое предположение заключается в том, что это связано с их простотой (придерживаясь очень немногих примитивов). (EDIT2: Очевидно также благодаря неоспоримым в основном находятся в памяти)

Во всяком случае, что о более сложных datastructures как иерархии деревьев и любит. С БД, как Redis вы должны построить структуру, основанную на «плоской» хэши со ссылками, тогда как с документами БД, как CouchDB вы просто создать структуру себя нравится:

"menu": { 
    "id": "file", 
    "value": "File", 
    "popup": { 
     "menuitem": [ 
      { 
       "value": "New", 
       "onclick": "CreateNewDoc()" 
       }, 
       { 
       "value": "Open", 
       "onclick": "OpenDoc()" 
       }, 
       { 
       "value": "Close", 
       "onclick": "CloseDoc()" 
       } 
     ] 
} 

Если у меня есть структуры, как это, делает это даже иметь смысл использовать производительность redis и удобство использования?

Интересно, что ключевое значение и документ Базы данных сравниваются с 1: 1 очень часто, при обслуживании другой цели и/или использования ИМХО.

EDIT:

Что я ищу: вообще-то я хотел бы иметь JSON-подобный DB магазин, который дает мне легкость определения и создания сложных структур на лету и получение хорошие вещи от использования Базы данных-системы (переход на другой ресурс, скорость, ...).

Спасибо!

Answer 1

Если у меня есть такие структуры, имеет ли смысл использовать redis производительность и удобство использования?

Структура вы изображали состоит из внедренных данных в JSon документе, однако даже с базами данных документов есть еще разница между embedded и referenced/linked данных. Если вы вложите много данных в один документ, вы можете столкнуться с проблемами производительности и фрагментацией данных. С другой стороны, привязка является более гибкой, но требует некоторой логики соединения. Подводя итог - это зависит от вашей модели домена и проблемы, которую вы пытаетесь решить. Что касается redis, то есть библиотеки, такие как ohm, которые обеспечивают большую абстракцию данных уровня на основе OOP.

Что я ищу: вообще-то я хотел бы иметь JSON-подобный DB магазин, который дает мне легкость определения и построения сложных структур на лету и получать хорошие вещи от использования Базы данных-системы (переход на другой ресурс, скорость, ...).

Хотя mongodb является, вероятно, самой популярной базой данных документа, за которой следует couchdb, вы также можете попробовать другие решения, такие как arangodb или orientdb. Каждый из них построен поверх некоторой философии, которая может обеспечить преимущества в определенных областях по сравнению с другими решениями, например. couchdb's map-reduce способ запросов может не подходить для всех, но он прочен.

Answer 2

Хранилища с ключевыми значениями, такие как Redis, работают так хорошо, потому что они хранят данные в памяти, которые вы можете читать/записывать во много раз быстрее, чем данные, хранящиеся на диске.

Проблема с хранением в памяти - это отказоустойчивость: если Redis неожиданно отключается, память очищается, и все ваши данные теряются. Таким образом, Redis подходит, когда вы часто читаете и записываете данные, но вы не против, если эти данные будут потеряны. Например: сеансы входа в систему, где потеря данных означает, что пользователи снова заходят в систему.

CouchDB и другие хранилища данных хранят скорость обмена для отказоустойчивости, гарантируя, что ваши данные более безопасны при большем количестве обстоятельств. Хранилища документов, такие как CouchDB, также предоставляют запросы, позволяя вам искать и анализировать данные, которые вы не можете сделать с Redis. Хранилище документов, такое как CouchDB, подходит, когда вы читаете и записываете данные, которые вы не можете позволить себе потерять произвольно.