Schemaless-базы данных

[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 того не стоит.

Comments

Хм-ммм...

[de_nada]

>1. Когда база используется как хранилище без обработки.

Я в этом месте вдруг вспомнил почему-то одну статью на Хабре, где в комментариях упоминали некую файловую систему (название протуканил, хоть убей!), которая пишет быстрее, чем читает.
Там какая-то хитрость была в непрерывном линейном сливе на носитель потока данных в структуру а-ля журнал/лог - отсюда скорость. А вот читалось медленно как раз оттого, что потом драйвер FS был вынужден во всём этом слитом "структур-лесс" (не, конечно, какая-то структурированность и/или реперы там обязаны бвть) великолепии как-то ориентироваться.

Просто "музыкой навеяло"...

С уважением.

[freya-victoria.livejournal.com]

А можно вопрос почти офф-топик? :)
Ты, помнится, когда-то предлагал учить начинающих программистов сперва SQL. Можешь порекомендовать какой-то годный учебник, который ты считаешь достаточно хорошим? На английском тоже подойдет. Желательно, чтоб там было побольше практических заданий.

[cross-join.livejournal.com]

"СУБД для программиста. Базы данных изнутри"
Там есть и ответы на вопросы зачем нужны неполно структурированные модели данных и когда их надо/можно применять.

[freya-victoria.livejournal.com]

Спасибо!

[beldmit.livejournal.com]

Можете тезисно пересказать эту часть?

[cross-join.livejournal.com]

Другие подходы и модели данных 40
Модель «Сущность-атрибут-значение» (EAV) 40
Неполно структурированные модели данных 49
Документ-ориентированная модель и NoSQL 52
Многомерные модели данных 57
О применимости NoSQL 61
Множественная и навигационная обработка, менеджеры записей 66
Объектная модель и объектно-реляционная проекция 70
SQL как универсальный входной язык 80
...
Неполно структурированные данные и высокая нагрузка 173
Относительность понятия высокой нагрузки 173
Особенности использования РСУБД и НСМД (NoSQL) 175
...
РСУБД и неполно структурированные данные 249
Поддержка XML 250
Поддержка JSON 258

[beldmit.livejournal.com]

Я это предлагал из общих соображений, а не конкретно опираясь на учебник :-(

[freya-victoria.livejournal.com]

Ну мало ли, я подумала, вдруг у тебя и конкретный учебник на примете есть
Но мне там уже выше порекомендовали :)

[vitus_wagner]

По-моему, "Введение в SQL" Граббера это то что надо для совсем начинающих. С практичностью там, конечно, не очень, но очень сложно придумать такое практичное задание, которое было бы интересным всем подряд. Там что-то вроде каталога фильмотеки по-моему используется.

[freya-victoria.livejournal.com]

Спасибо!

[qkowlew.livejournal.com]

Скоро полвека, а суть проблем та же.

В какой-то древней книжке, где обсуждались особенности синтаксиса Алгола-60 (!), и которую я читал, когда программировал на PL-1, говорилось с сожалением о том, что нету, нету у "нынешних" программистов на языке высокого уровня достаточной дисциплины мышления! Что им нужен внешний дисциплинирующий фактор, НАПРИМЕР, на уровне синтаксиса языка.

:)

[gineer.livejournal.com]

Монадами их, монадами... ;)

[slobin.livejournal.com]

Упорно читаю schemaless как shameless.

... Эх, Додоша, а ещё математик ...

[vitus_wagner]

Очитка по Фрейду!

[cross-join.livejournal.com]

В приципе, это небольшое преувеличение.
Данные в неглиже, тсзать.

!

[de_nada]

Это ещё цветочки - я с налёта вообще прочёл как "shemale"... Во где жЭсть-то! :)))

С уважением.

[qkowlew.livejournal.com]

Я как "shemales" - ещё круче... :(

[beldmit.livejournal.com]

Устроили тут конкурс на призы поручика Ржевского, панимаишь...

[raydac.livejournal.com]

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

[yurikhan]

+1, жидкие базы данных — зло.

[mikeiva.livejournal.com]

В NoSQL это придётся делать в приложении, потому что альтернатива — в мозгах программистов — слишком ненадёжна

Зачем в мозгах, в тетрадочке же!

На позапрошлой работе была священная черная тетрадочка, в которой были структуры всех таблиц (mumps, если что). Потом оттуда ушел я, еще через полгодика - все остальные, потом туда взяли новых программистов, а новые программисты позвали меня - разбирать коды программ и рисовать им утраченные схемы :)

[besm6.livejournal.com]

Ключевое слово - "документ-ориентированный". В смысле, что задача про документы характерна тем, что по чему реально надо искать, выясняется ПОСЛЕ того, как документ вместе с метаинформацией создан. В момент создания предсказать, по чему будут искать... Ну, половину, может, удается.

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

[beldmit.livejournal.com]

Ну да, кто-то из знакомых рассказывал про важное рабочее письмо, которое каждый раз приходится искать по фразе типа "тупые ублюдки". Но тут уж да, полнотекстовый поиск без вариантов или хотя бы нормализация.

[besm6.livejournal.com]

Если что, под полнотекстовым поиском я понимаю не поиск точной фразы, а поиск чего-то похожего на. Т.е. введенные слова плюс-минус рядом, в произвольном порядке (но предпочтительнее в заданном) и в произвольной грамматической форме. Какая-то нормализация для работы такой конструкции, безусловно, понадобится. Но насколько я понимаю, в реальной жизни реально работающие поиски такого рода пользуются каким-то другим интерфейсом, не реляционным, и лежит под ним не РСУБД.

[beldmit.livejournal.com]

Я понимаю. И подозреваю, что в реальной жизни они fuzzy.

[dph.livejournal.com]

Ну да, для этого есть SOLR, Elastic Search, Sphynx
И это редкий пример NoSQL, которые реально имеют смысл )

[scolar.livejournal.com]

Всякий раз, когда я задаю подобные вопросы, мне отвечают, что
а) я динозавр
б) it's blazingly fast

[beldmit.livejournal.com]

б) — С какой скоростью вы печатаете на машинке?
— 2000 символов в минуту, но такая фигня получается...

[dph.livejournal.com]

Ну, вообще-то, есть еще любимый мной подход сериализации объектов в БД.

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

А в качестве движка для неструктурированных данных - лучше всего, разумеется, json/jsonb в том же PostgreSQL.

[beldmit.livejournal.com]

Бартунов утверждает, что не только лучше, но и быстрее. Работать-то с ними как, если они не структурированные?

[dph.livejournal.com]

Неструктурированные с чьей точки зрения?
Для AppLayer - все там жестко структурировано, DAO layer работает только с полноценными объектами (и при таком подходе всякие ORM лишаются смысла, к счастью).
Для PersistanceLayer (собственно СУБД) мы сохраняем нормализацию - содержимое json является неделимым на уровне СУБД.

Единственное, что часть значимых для поиска полей из json вытаскиваем в нормальные колонки и строим индексы. Да, теоретически можно делать индексы и по jsonb, но я вот пока не готов так делать.

Но если мне когда-нибудь понадобиться какой-нибудь экзотический отчет на уровне СУБД - то я знаю, что я смогу его сделать через доступ к json-содержимому.

И производительность, конечно, гораздо выше, чем если бы я нормализовал все содержимое json и хранил 100500 колонок и табличек.