Schemaless-базы данных
Nov. 11th, 2015 12:08 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
beldmitЯ давно хотел написать этот пост, но до разговора с Фёдором Сигаевым на PGConf.eu стеснялся.
Одно из позиционирований NoSQL-ных баз данных — отсутствие схемы. Я всегда этот момент не понимал. Собственно, у меня на рабочем столе (физическом) полное отсутствие схемы, и помойкой это не является только потому, что я её так не называю. В смысле, мало запихнуть данные в куда-нибудь, с ними надо ещё работать: искать по атрибутам или по их значениям, а значит где-то эти значения должны регламентироваться. Не будут регламентироваться — рано или поздно получите атрибуты topic, Topic и TOPICS с одной семантикой.
В SQL-базе эту регламентацию достигают проверкой на уровне имён колонок. В NoSQL это придётся делать в приложении, потому что альтернатива — в мозгах программистов — слишком ненадёжна. И то и другое приводит к багам разной степени уловимости, даже при использовании hstore мы вдвоём с коллегой по этому грабельному полю потоптались.
То есть по большому счёту летать вся эта структурированность будет в паре случаев.
1. Когда база используется как хранилище без обработки. Максимум - проверить, что то, что передали в качестве XML, таковым является.
2. Когда “структурированные” данные обрабатываются и пишутся локально (например, параметры для разных типов заданий в очереди). И то в этом случае приходится работать с такой структурой как минимум в 2 местах — при чтении и при записи.
Во всех остальных случаях получаются размазанные по приложению метаданные, которые удобней держать в одной точке — в базе. Удобнее, например, потому как grep-ать не надо, а можно описание таблицы посмотреть. Нельзя построить внешние ключи (ну, ORM это частично компенсирует) и навести типизацию тоже можно довольно ограниченно.
Лично я до сих пор использую из таких "бессхемных" типов в PostgreSQL ровно 2 — hstore и XML. XML при этом в моей задаче можно было бы заменить массивом hstore или отдельной таблицей, но из соображений отслеживания изменений оказалось проще внедрить XML. Можно было бы с таким же успехов json воткнуть, впрочем.
Конечно, недооценивать экономию усилий при добавлении новой колонки не надо. Это часто бывает самостоятельным геморроем, особенно если требуется zero downtime. Но пока что, по ощущениям, schemaless того не стоит.
Одно из позиционирований NoSQL-ных баз данных — отсутствие схемы. Я всегда этот момент не понимал. Собственно, у меня на рабочем столе (физическом) полное отсутствие схемы, и помойкой это не является только потому, что я её так не называю. В смысле, мало запихнуть данные в куда-нибудь, с ними надо ещё работать: искать по атрибутам или по их значениям, а значит где-то эти значения должны регламентироваться. Не будут регламентироваться — рано или поздно получите атрибуты topic, Topic и TOPICS с одной семантикой.
В SQL-базе эту регламентацию достигают проверкой на уровне имён колонок. В NoSQL это придётся делать в приложении, потому что альтернатива — в мозгах программистов — слишком ненадёжна. И то и другое приводит к багам разной степени уловимости, даже при использовании hstore мы вдвоём с коллегой по этому грабельному полю потоптались.
То есть по большому счёту летать вся эта структурированность будет в паре случаев.
1. Когда база используется как хранилище без обработки. Максимум - проверить, что то, что передали в качестве XML, таковым является.
2. Когда “структурированные” данные обрабатываются и пишутся локально (например, параметры для разных типов заданий в очереди). И то в этом случае приходится работать с такой структурой как минимум в 2 местах — при чтении и при записи.
Во всех остальных случаях получаются размазанные по приложению метаданные, которые удобней держать в одной точке — в базе. Удобнее, например, потому как grep-ать не надо, а можно описание таблицы посмотреть. Нельзя построить внешние ключи (ну, ORM это частично компенсирует) и навести типизацию тоже можно довольно ограниченно.
Лично я до сих пор использую из таких "бессхемных" типов в PostgreSQL ровно 2 — hstore и XML. XML при этом в моей задаче можно было бы заменить массивом hstore или отдельной таблицей, но из соображений отслеживания изменений оказалось проще внедрить XML. Можно было бы с таким же успехов json воткнуть, впрочем.
Конечно, недооценивать экономию усилий при добавлении новой колонки не надо. Это часто бывает самостоятельным геморроем, особенно если требуется zero downtime. Но пока что, по ощущениям, schemaless того не стоит.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-11-11 09:55 am (UTC)Ты, помнится, когда-то предлагал учить начинающих программистов сперва SQL. Можешь порекомендовать какой-то годный учебник, который ты считаешь достаточно хорошим? На английском тоже подойдет. Желательно, чтоб там было побольше практических заданий.
no subject
Date: 2015-11-11 10:00 am (UTC)Там есть и ответы на вопросы зачем нужны неполно структурированные модели данных и когда их надо/можно применять.
no subject
Date: 2015-11-11 10:01 am (UTC)no subject
Date: 2015-11-11 10:40 am (UTC)no subject
Date: 2015-11-11 10:49 am (UTC)Модель «Сущность-атрибут-значение» (EAV) 40
Неполно структурированные модели данных 49
Документ-ориентированная модель и NoSQL 52
Многомерные модели данных 57
О применимости NoSQL 61
Множественная и навигационная обработка, менеджеры записей 66
Объектная модель и объектно-реляционная проекция 70
SQL как универсальный входной язык 80
...
Неполно структурированные данные и высокая нагрузка 173
Относительность понятия высокой нагрузки 173
Особенности использования РСУБД и НСМД (NoSQL) 175
...
РСУБД и неполно структурированные данные 249
Поддержка XML 250
Поддержка JSON 258
no subject
Date: 2015-11-11 10:09 am (UTC)no subject
Date: 2015-11-11 10:14 am (UTC)Но мне там уже выше порекомендовали :)
no subject
Date: 2015-11-11 10:31 am (UTC)no subject
Date: 2015-11-11 10:32 am (UTC)