Что такое база данных ключей / значений?

Я просматривал страницу Википедии для NoSQL, и там перечислены несколько вариантов базы данных хранилища ключей / значений, но я не могу найти какие-либо подробности о том, что означает хранилище ключей / значений в этом контексте. Может ли кто-нибудь объяснить или связать объяснение со мной? Кроме того, когда я буду использовать такую ​​базу данных?

Вы знакомы с концепцией пары ключ / значение? Предполагая, что вы знакомы с Java или C #, это на языке карты / hash / datatable / KeyValuePair (последнее в случае C #)

Как это работает, продемонстрировано на этом небольшом примере диаграммы:

Color        Red
Age          18
Size         Large
Name         Smith
Title        The Brown Dog

Если у вас есть ключ (слева) и значение (справа) ... обратите внимание, что это может быть строка, int или тому подобное. Большинство объектов KVP позволяют вам хранить любой объект справа, потому что это просто значение.

Поскольку у вас всегда будет уникальный ключ для конкретного объекта, который вы хотите вернуть, вы можете просто запросить базу данных об этом уникальном ключе и получить результаты обратно от того, какой узел имеет объект (вот почему это хорошо для распределенных систем, поскольку существуют другие вещи, такие как опрос первых n узлов для возврата значения, соответствующего другим узлам, возвращается).

Теперь мой пример выше очень прост, так что вот немного лучшая версия KVP

user1923_color    Red
user1923_age      18
user3371_color    Blue
user4344_color    Brackish
user1923_height   6' 0"
user3371_age      34

Итак, как вы можете видеть, генерация простого ключа состоит в том, чтобы ввести «пользователь» уникальный пользовательский номер, подчеркивание и объект. Опять же, это простой вариант, но я думаю, что мы начинаем понимать, что до тех пор, пока мы можем определить часть слева и последовательно отформатировать ее, мы можем извлечь значение.

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

app_setting_width      450
user1923_color         Red
user1923_age           18
user3371_color         Blue
user4344_color         Brackish
user1923_height        6' 0"
user3371_age           34
error_msg_457          There is no file %1 here
error_message_1        There is no user with %1 name
1923_name              Jim
user1923_name          Jim Smith
user1923_lname         Smith
Application_Installed  true
log_errors             1
install_path           C:\Windows\System32\Restricted
ServerName             localhost
test                   test
test1                  test
test123                Brackish
devonly
wonderwoman
value                  key

Вы понимаете, что все они будут храниться в одной большой «таблице» на распределенных узлах (за этим стоит математика), и вы просто спросите распределенную систему о нужном вам значении по имени.

По крайней мере, это мое понимание того, как все это работает. Я могу ошибаться, но это основа.

обязательная ссылка на Википедию http://en.wikipedia.org/wiki/Associative_array

В терминах SQL база данных NoSQL представляет собой одну таблицу с двумя столбцами: один является (первичным) ключом, а другой - значением. И это все, в этом вся магия NoSQL.

Вы бы использовали NoSQL по одной основной причине: масштабируемость.

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

Только самые большие веб-сайты на самом деле используют весь потенциал NoSQL, то есть Facebook, с тысячами серверов, работающих под управлением Cassandra .

Я настоятельно рекомендую прочитать этот пост, сравнивая SQL, NoSQL и ORM:

http://seldo.com/weblog/2010/07/12/in_defence_of_sql

Я предполагаю, что у вас есть базовые знания о движении NoSQL и моделях нереляционных баз данных.

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

Хранилища Key Value и движение NoSQL

В целом, SQL удалось обработать специально структурированные данные и разрешать высокодинамичные запросы в соответствии с потребностями соответствующего отдела.

Несмотря на то, что в этой конкретной области реальных конкурентов для SQL пока нет, сценарий использования в повседневных веб-приложениях отличается. Вы не найдете высокодинамичный диапазон запросов, полный внешних и внутренних объединений, объединений и сложных вычислений для больших таблиц. Обычно вы найдете очень объектно-ориентированный способ мышления. Особенно с принятием таких шаблонов, как MVC, данные в бэкэнде обычно моделируются не для базы данных, а для логической целостности, которая также помогает людям справляться с пониманием огромных программных инфраструктур. То, что делается для помещения этих объектно-ориентированных моделей в реляционные базы данных, - это большая нормализация, которая приводит к сложной иерархии таблиц и полностью противоречит основной идее объектно-ориентированного программирования.

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

Именно здесь в игру вступают магазины Key Value. Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship, Сами данные обычно являются своего рода примитивом языка программирования (строка, целое число, массив) или объектом, который маршалируется связыванием языков программирования с хранилищем значений ключа. Это заменяет необходимость в фиксированной модели данных и делает требование к правильно отформатированным данным менее строгим.

They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval, Самым большим отличием для «более простых» хранилищ является то, как вы можете (или не можете) проверять подлинность или получать доступ к различным хранилищам (если это возможно). В то время как преимущества скорости при хранении и извлечении данных могут быть причиной для их рассмотрения по сравнению с обычными базами данных SQL, еще одно большое преимущество, которое возникает при использовании хранилищ значений ключей, заключается в том, что результирующий код имеет тенденцию выглядеть чистым и простым по сравнению со встроенными строками SQL в ваш язык программирования. Это то, что люди склонны бороться с объектно-реляционными структурами отображения, такими как Hibernate или Active Record. По-видимому, наличие объектно-реляционных сопоставителей в основном эмулирует хранилище значений ключей, добавляя много действительно сложного кода между базой данных SQL и объектно-ориентированным языком программирования.

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

when would I use such a database? Could someone explain or link an explanation to me?
Его больше архитектурного решения, и дискуссионная один ... Вы должны учитывать множество факторов, такие как масштабируемость, производительность и т.д. ...

Просмотрите слайды / статьи ниже, и вы поймете, когда, почему и почему не стоит использовать хранилище ключей :)

• Нереляционные базы данных и хранилища ключей и значений
• Key-Value-Stores - ключ к масштабированию?
• http://highscalability.com/blog/category/key-value-store [необходимо прочитать]
• http://ayende.com/Blog/archive/2010/03/29/that-no-sql-thing-keyvalue-stores.aspx

Другие объяснили это, но я все равно собираюсь нанести удар.

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

Ценность - это просто любая ценность. Способ хранения данных непрозрачен для самой базы данных. Когда вы сохраняете данные в хранилище ключей / значений, база данных не знает или не заботится, является ли это XML, JSON, текстом или изображением. По сути, то, что мы делаем в хранилище ключей / значений, переносит ответственность за понимание того, как данные хранятся из базы данных, в приложения, которые извлекают наши данные. Поскольку у вас есть только один диапазон ключей для каждой корзины, очень легко распределить ключи по многим серверам и использовать методы распределенного программирования, чтобы обеспечить быстрый доступ к этим данным (каждый сервер хранит диапазон данных) ,

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

Есть несколько причин, по которым вы можете использовать базу данных ключ / значение:

• Когда производительность записи является вашим наивысшим приоритетом. Mozilla Test Pilot использует базу данных ключ / значение для быстрой записи данных.
• Когда чтения гарантированно происходят только PK.
• Когда вы работаете с плоской моделью данных.
• Когда вы работаете с богатой, сложной моделью данных, которая не может быть смоделирована в СУБД.

Причин для использования базы данных ключ / значение примерно столько же, сколько и для использования СУБД, и столько же аргументов, чтобы оправдать одно над другим. Важно взглянуть на то, как вы запрашиваете свои данные, и понять, как этот шаблон доступа к данным определяет, как вы собираетесь вставлять и хранить данные.

Просто помните, что база данных ключ / значение - это всего лишь один тип базы данных NoSQL.

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

create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);

Именно так были все базы данных, примером чему может служить Berkeley DBM , начиная с 1979 года. С тех пор дела продвигаются вперед ( в любой RDBMS может быть много значений на ключ). Для многих приложений достаточно хранилища значений ключей (например, именно так sendmail хранит свои псевдонимы). Но если вы обнаружите, что предварительно обрабатываете значение в своем собственном коде (или объединяете строки для создания своего «ключа»), возможно, разбиваете значение на разделителе или анализируете его, прежде чем вы сможете его использовать, вам, вероятно, будет лучше с СУБД и на самом деле хранить его таким образом.