0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Существуют четыре основных типа СУБД NoSQL. В этом материале мы рассмотрим базу данных типа "ключ-значение". Такие БД обычно используют хеш-таблицу, где присутствуют уникальный ключ и указатель на конкретный объект данных. Ключ бывает синтетическим либо автоматически сгенерированным, а значение бывает представлено JSON, строкой, блобом (Binary Large Object) и т. д.</p>
1
<p>Существуют четыре основных типа СУБД NoSQL. В этом материале мы рассмотрим базу данных типа "ключ-значение". Такие БД обычно используют хеш-таблицу, где присутствуют уникальный ключ и указатель на конкретный объект данных. Ключ бывает синтетическим либо автоматически сгенерированным, а значение бывает представлено JSON, строкой, блобом (Binary Large Object) и т. д.</p>
2
<p>Говоря о БД "ключ-значение", стоит упомянуть о таком понятии, как блок (bucket) - это логическая группа ключей, не группирующих данные физически. При этом в различных блоках бывают идентичные ключи. За счёт кеширующих механизмов, работающих на основе маппингов, производительность базы данных существенно вырастает. Дабы прочитать значение, надо знать и ключ, и блок, т. к. на деле ключ является хешем (блок, плюс ключ).</p>
2
<p>Говоря о БД "ключ-значение", стоит упомянуть о таком понятии, как блок (bucket) - это логическая группа ключей, не группирующих данные физически. При этом в различных блоках бывают идентичные ключи. За счёт кеширующих механизмов, работающих на основе маппингов, производительность базы данных существенно вырастает. Дабы прочитать значение, надо знать и ключ, и блок, т. к. на деле ключ является хешем (блок, плюс ключ).</p>
3
<p>Вообще, в данной модели СУБД нет ничего сложного, да и реализовать её несложно. Если же вспомнить<a>теорему CAP</a>, то становится очевидно, что описываемые нами хранилища хороши в плане доступности (Availability), а также неплохи с точки зрения устойчивости к разделению (Partition tolerance). Но при всём при этом они однозначно проигрывают, если речь идёт о согласованности данных (Consistency).</p>
3
<p>Вообще, в данной модели СУБД нет ничего сложного, да и реализовать её несложно. Если же вспомнить<a>теорему CAP</a>, то становится очевидно, что описываемые нами хранилища хороши в плане доступности (Availability), а также неплохи с точки зрения устойчивости к разделению (Partition tolerance). Но при всём при этом они однозначно проигрывают, если речь идёт о согласованности данных (Consistency).</p>
4
<p>В качестве примера давайте глянем на набор данных в таблице ниже. Ключ -название страны, значение - список адресов в стране:</p>
4
<p>В качестве примера давайте глянем на набор данных в таблице ниже. Ключ -название страны, значение - список адресов в стране:</p>
5
<p>БД этого типа даёт возможность читать и записывать значения посредством ключа следующим образом: • Get(key) возвращает значение, которое связано с переданным ключом; • Put(key, value) связывает значение с ключом; • Multi-get(key1, key2, ..., keyN) возвращает список значений, которые связаны с переданным ключами; • Delete(key) служит для удаления записи для ключа из хранилища.</p>
5
<p>БД этого типа даёт возможность читать и записывать значения посредством ключа следующим образом: • Get(key) возвращает значение, которое связано с переданным ключом; • Put(key, value) связывает значение с ключом; • Multi-get(key1, key2, ..., keyN) возвращает список значений, которые связаны с переданным ключами; • Delete(key) служит для удаления записи для ключа из хранилища.</p>
6
<p>Несмотря на то, что БД типа "ключ-значение" неплохо себя зарекомендовали в определённых ситуациях, недостатки у них, разумеется, тоже присутствуют. Например, модель не предоставляет стандартные возможности для баз данных - допустим, атомарность транзакций либо согласованность данных при одновременном исполнении нескольких транзакций. То есть такие возможности должны предоставляться непосредственно самим приложением. Есть и второй существенный недостаток: когда происходит увеличение объёмов данных, поддерживать уникальные ключи становится проблемно. И чтобы эту проблему решить, надо каким-нибудь образом усложнять процесс генерации строк, дабы они оставались уникальными среди огромного набора ключей.</p>
6
<p>Несмотря на то, что БД типа "ключ-значение" неплохо себя зарекомендовали в определённых ситуациях, недостатки у них, разумеется, тоже присутствуют. Например, модель не предоставляет стандартные возможности для баз данных - допустим, атомарность транзакций либо согласованность данных при одновременном исполнении нескольких транзакций. То есть такие возможности должны предоставляться непосредственно самим приложением. Есть и второй существенный недостаток: когда происходит увеличение объёмов данных, поддерживать уникальные ключи становится проблемно. И чтобы эту проблему решить, надо каким-нибудь образом усложнять процесс генерации строк, дабы они оставались уникальными среди огромного набора ключей.</p>
7
<p>Тем не менее, такие базы есть, и они успешно работают. Наиболее популярные из них - Riak и Dynamo от Amazon.</p>
7
<p>Тем не менее, такие базы есть, и они успешно работают. Наиболее популярные из них - Riak и Dynamo от Amazon.</p>
8
<p><em>Источник - "<a>EXPLORING THE DIFFERENT TYPES OF NOSQL DATABASES</a>".</em></p>
8
<p><em>Источник - "<a>EXPLORING THE DIFFERENT TYPES OF NOSQL DATABASES</a>".</em></p>
9
9