Що таке база даних ключових даних / цінностей?

Я переглядав сторінку Вікіпедії для NoSQL, і в ній перераховано декілька варіантів бази даних ключів / цінностей, але я не можу знайти жодних деталей про те, що це означає в магазині Key / Value. Чи може хтось пояснити чи зв’язати мені пояснення? Також коли я буду використовувати таку базу даних?

Чи знайомі ви з концепцією пари ключ / цінність? Припускаючи, що ви знайомі з Java або C #, це мовою як карта / хеш / дані / 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

Отже, як ви бачите, проста клавіша генерації - це поставити "користувачеві" число userunique, підкреслення та об'єкт. Знову ж таки, це проста версія, але я думаю, ми починаємо розуміти, що до тих пір, поки ми можемо визначити частину зліва та мати її послідовний формат, ми можемо витягнути значення.

Зауважте, що немає обмеження на значення ключа (нормально, можуть бути деякі обмеження, наприклад, лише для тексту) або щодо властивості значення (можливо обмеження розміру), але поки що у мене не було дійсно складних систем. Спробуємо і підемо трохи далі:

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

Ви розумієте, що всі вони зберігатимуться в одній масивній "таблиці" на розподілених вузлах (за цим стоїть математика), і ви просто запитаєте в розподіленій системі значення, яке вам потрібно по імені.

Принаймні, це моє розуміння того, як це все працює. У мене можуть помилятися кілька речей, але це основи.

обов'язкове посилання на wikipedia http://en.wikipedia.org/wiki/Associative_array

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

Ви б використовували NoSQL з однієї основної причини: масштабованість.

Якщо вашій програмі потрібно обробити мільйони запитів в секунду, єдиний спосіб досягти цього - додати більше серверів. Це дуже дешево і просто з NoSQL. На відміну від цього, масштабування традиційної бази даних SQL набагато складніше.

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

Настійно рекомендую прочитати цю публікацію в блозі, порівнюючи SQL, NoSQL та ORM:

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

Я припускаю, що ви добре розумієте рух NoSQL і нереляційні моделі баз даних.

Ключове значення зберігання - одна з моделей бази даних, що не стосуються, як, наприклад, графіки, орієнтовані на документи моделі баз даних.

Ключові значення зберігання та рух 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 в Ваша мова програмування. Це те, з чим люди схильні боротись з об'єктно-реляційними структурами відображення, такими як сплячий режим або активний запис. Наявність об'єктивних реляційних картографів в основному, здається, емулює запас значень ключових даних, додаючи багато дійсно складного коду між базою даних SQL та об'єктно-орієнтованою мовою програмування.

Ціла громада людей збирається під тегом " NoSQL " і обговорює ці переваги, а також недоліки використання альтернатив реляційним системам управління базами даних. читати далі
Це трохи стара стаття, але мені здалося дуже корисною.

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

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

• Нереляційні бази даних та магазини ключів та цінностей
• Магазини ключових цінностей - ключ до масштабування?
• 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 використовує базу даних ключів / значень для швидкого запису даних.
• Коли читання гарантовано відбувається лише ПК.
• Коли ви працюєте з плоскою моделлю даних.
• Коли ви працюєте з багатою складною моделлю даних, яку неможливо моделювати в RDBMS.

Існує стільки ж причин використовувати базу даних ключів / значень, як і для використання RDBMS, і є стільки ж аргументів, щоб виправдовувати один над іншим. Важливо поглянути на те, як ви запитуєте свої дані і зрозуміти, як ця схема доступу до даних визначає, як ви збираєтеся вставляти та зберігати дані.

Пам'ятайте лише, що база даних ключів / значень - це лише один тип баз даних 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 зберігає свої псевдоніми). Але якщо ви виявите, що попередньо обробляєте значення у власному коді (або об'єднуєте рядки, щоб зробити свій "ключ"), можливо, розділивши його на роздільник або проаналізувавши його, перш ніж використовувати його, вам, ймовірно, буде краще з RDBMS і насправді зберігає його таким чином.