01_quetions.txt

NoSQL (4 июл, 2012 at 2:18 PM)

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

В идеальном разбиении данных на сущности данные не дублируются.
Созданы такие БД для компактного хранения, быстрых частых выборок данных, но не подходят для частых изменений.

Индекс в общем сложная структура, при изменения данных он блокируется для записи (либо весь, либо его существенная часть, не важно). 
В этот момент никто не может вносить в него изменения. 
Помогает решение SQL + partitioning, когда строки в таблице разбиваются на группы, партиции, с независимым хранением данных, 
индексами и т.п. Хорошо, если надо иметь и архив, и актуальные записи в одной таблице. 
Если же идет просто много изменений, то это полумера. 
Ну на 2,3,10 ... 20 партиций разобъем, но не больше. 
Т.е. плохая горизонтальная масштабируемость.

Здесь нужны распределенные базы данных, такие называют БД NoSQL. 
Используются гигантами типа Google, Facebook, etc. Есть CAP-теорема, 
что в распределенных вычислениях можно добиться только два из трех 
свойств C(согласованность), A(доступность), P(устойчивость к разрыву связей). 
Надо классифицировать известные NoSQL базы данных в терминах теоремы. Есть несколько типов NoSQL БД

-ключ-значение (Redis, MonoDB, ... )
-документо-ориентированные (то же самое что и ключ-значение)
-колоночные? (ничего про них не знаю)
-граф-ориентированные (neo4j)

В key-value БД атомарность на уровне ключа (ключевые слова: DHT). 
Каждому ключу соответствует одно значение, которое может только целиком изменяться, удаляться и т.п. 
По ключу быстро определяется и узел с данными, и значение. 
Как находится узел, видимо надо смотреть в направлении протоколов p2p, dht. 
Значение - данные в произвольном формате, например, json закодированные структуры. 
Никакой типизации значения нет. Что с одной стороны хорошо, т.к. примитивные поля в SQL: строка, 
число, дата - это архаизм, но переносит валидацию данных на плечи программиста.

Индексы есть, но часто поиск по критерию приводит к полному перебору. 
Выборка разпределяется между узлами по технологии MapReduce. 
Далее нету JOIN, следовательно для эффективных выборок данные дублируют. 
Тут начинаются офигенные халивары между упертыми старперами и не до конца разбирающейся молодежью. 
Первые ужасаются полному перебору и дубляжу данных.
Вторые говорят, что полный перебор фигня, если у тебя милион компов, при этом, 
правда, забывая, что милион компов делается для милиона запросов. 
В общем система сделана для быстрых частых записей, но не подходят для частых больших выборок.

В граф-ориентированных NoSQL БД поддерживаются узлы и отношения между узлами. Пример, neo4j.