Pull to refresh

Comments 67

Насчет типов, зависит от языка и фронтенда самой базы. Если есть нормальная интроспекция, хватит одних бинарных. LevelDB (младший брат BigTable) как раз только бинарные ключи-значения и обслуживает. Но, например, Riak поверх нее уже сам приводит все в кортежи строк, чисел, списков и т. п.

Ну и денормализация — это тоже личный выбор архитектора. В реляционных базах тоже можно нахамить, чтобы летало.

Есть еще один подвох. No SQL создает ложное впечатление, что можно не знать SQL. Все просто же: положить/достать. Большая консистентная мапа, ура! А на самом деле, если не язык запросов, то уж правила Кодда знать как раз обязательно. Они не на пустом месте появились, мы можем делать вид, что работаем с произвольными кортежами, но в большинстве случаев данные представляют собой все те же таблицы и отношения между ними. Больше чем теоретики реляционных баз про это все не думал никто.
Полностью согласен. Нужно хорошо понимать классическую реляционную теорию, нанюхаться пыли с MySQL/Oracle чтобы предвидеть развитие модели данных приложения в NoSQL, угадать варианты деноромализации — чтобы приложение не пришлось потом несколько раз переписывать.
Правильные выводы.
Но я бы дополнил их и плюсами в сторону NoSQL. Ведь для не малого количества задач, на NoSQL они ложатся как родные, а в реляционки никак.
Во вторых, все NoSQL предназначены для какого-то конкретного порядка CAP ереси ;).И для кадого из порядков выводы будут иметь совершенно различную окраску. Если внимательно смотреть на любой, даже банковский или космический проект — то можно найти удовлетворяющее допущение.
В третьих. Если в голове у акитекта с мегасуперопытом и образованием нет приязни с NoSQL — то и не нужно мучатся. Ведь в NoSQL данные часто не нормализуются, и вообще игнорируется большинство догм реляционок. По этому хороший и эффективный NoSQL это всегда ересь для опытного реляционщика. Совершенно другие паттерны, принципы. Самое главное не пытаться сделать NoSQL по принципам реляционок.
Согласен, плюсов у NoSQL решений немало. Взять к примеру гибкую структуру строки — пихай столько атрибутов, сколько нужно — и они еще автоматически хранятся отсортированными. И писать можно на любую ноду кольца серверов — идеальный мастер-мастер.

Но не покидает 2 ощущения:
— да этож набор memcached, только под другим соусом со всеми вытекающими
— это нужно ограниченному кругу зверских приложений, понимающих ограничения CAP — соцсети, некоторые виды электронной коммерции и т.п.
Ну зачем же зверские приложения… Практически любое web-приложение (кроме как раз электронной коммерции) не требует жесткой констистенции… Соответственно учитывая описанные преимущества по горизонтальному масштабированию БД (ведь очень хорошо если проект «стрельнит» и ему понадобится такое масштабирование) использование NoSQL именно в вебе ОЧЕНЬ и ОЧЕНЬ оправдано…

Можно говорить о том, что история это УЖЕ доказала…
Согласен, NoSQL для веба — доказанный факт. А если учесть бурный рост мобильных приложений с подобной NoSQL-логикой — можно ждать прямо прорыва этого направления.
Никак не могу понять в чем профит от «пихай столько атрибутов, сколько нужно». Есть объект, у него есть атрибуты, атрибуты заданы в приложении. В БД не может быть каких-то еще атрибутов, кроме определенных — приложение не сможет их обработать. Может быть меньше, если часть из атрибутов не заданы (читай =null), но это надо учить приложение, создавая запись, отсекать пустые атрибуты. А это работа для программиста, усложнение архитектуры. Получается, колонки все-равно есть, только теперь схема данных хранится не в БД, а в приложении.
Именно про это и говорилось… Что захотелось изменить схему, изменил приложение и всё… А любая операция с SQL таблицами размером в десятки-сотни гигабайт занимает ОЙКАКМНОГО времени… а если еще и реплицируемая то нувообщелучшенеприкасаться

После перехода на NoSQL ощутил почти экстаз от свободы с которой реализуются новые «хотелки»
Это не недостаток самой идеи реляционных баз данных. Сейчас крайне модно и даже никто не видит подвоха — создавать 2 конкурирующих сервера, решающих одну и ту же задачу — на языке вроде джавы, шарпа, который «взаимодействует» с БД. Вся цель его, всего лишь ослабить реляционную модель, бороться с ней, дублировать логику (писать классы, отражающие таблицы), гонять данные туда сюда с сериализацией, создать свой транзакционный механизм, который, конечно, слабее. Т.е. в любом проекте с БД, создается такой велосипедище, причем это считается правилом хорошего тона.

Думаю, сервер должен быть один. В теории. Не надо дублировать логику, дублировать схему. К сожалению, на мой взгляд реляционные СУБД для этого могли бы сгодиться, но они не доделаны. SQL хорош, но недостаточен. А процедурные языки унылы и неудобны. Бросили нас производители реляционных СУБД и гоняются только между собой за производительность некоторых операций.
Хорошо сказали, пробрало до глубин :-)
Я не утверждал что это какой-то недостаток… Для пашки поля лучше использовать трактор, но для передвижения по трассе Porsche явно лучше…

В моем понимании «Одна БД», это какой-то такой гоночный трактор… круто конечно, но боюсь что не очень реализуемо, так как архитектурные принципы всё-таки различны…
> В моем понимании «Одна БД», это какой-то такой гоночный трактор…
> круто конечно, но боюсь что не очень реализуемо, так как архитектурные принципы всё-таки различны…

Подход NoSQL + SQL + ООП в рамках одной СУБД уже реализован.

А по поводу гоночного трактора… см. картинку здесь: habrahabr.ru/company/intersystems/blog/144306/
:D за картинку спасибо… но её интерпритация на мой взгляд весьма не однозначна… ;)))
Я скорее ощутил обратный эффект. Добавить колонку и в SQL мгновенная операция. Переименовать колонку/аттрибут — в SQL мгновенно, в noSQL нужно лопатить все записи. Изменить формат записи (например, решили хранить содержимое поля в апперкейсе) — в SQL долго, зато никто не увидит промежуточный результат, пока операция не закончится; в noSQL также придется лопатить все записи, только при этом писать map-reduce скрипт, и пока он будет работать, клиенты будут видеть записи в обоих форматах. Останавливать сервис на время обновления? В чем гибкость?
Добавить колонку и в SQL мгновенная операция.
— а если в таблице миллионы записей, все станет колом на полчаса? И эта одна колонка попадет во все кортежи, хотя она нужна может нескольким или вообще одному. NoSQL скорее хранит «колонки» компактно и займут они места столько, сколько нужно.

Также, придется добавлять в таблицу колонки на все случаи жизни и превратится она в… монстра — а БД скорее всего имеет ограничение на число колонок, причем жесткое.

За все SQL серверы не скажу, в Oracle добавить/удалить колонку действительно мгновенно, независимо от объема таблицы. Ограничение на число колонок есть — не больше одной тысячи. Но даже в денормализованном DWH не видел таблиц с более чем 200 полями. У вас действительно так много аттрибутов у объектов? И null-ы, кстати, место почти не занимают.
Просто идеологически в одной таблице = отношении хранятся кортежи = конкретные факты. А в NoSQL записи/строке факт может иметь столько видов разных, что их заранее очень сложно спрогнозировать и добавлять колонки каждый раз при появлении нового атрибута сущности — не выход же. Например поля анкеты клиента, которые нужно тупо вывести на экран красиво — для всех стран мира.

Еще пример — посты юзера в блоге. Можно ввести кросс-таблицу, а можно каждый факт поста отразить в атрибуте таблицы юзеров в виде $ИД-поста_таймстамп-поста и моментально одним запросом по ИД юзера их дернуть без джойнов, что очень помогает если связей много.

Еще пример — тэги. Объект связан с тэгами. Нужно построить облако тегов для всех объектов. Либо будем танцевать с джойнами — что при больших объемах равносильно смерти. Либо сразу денормализуем в одну запись о тэги информацию о связанных с ним объектах в атрибутах тэга:

железный авто_34 авто_3424 авто_7874 самолет_234232…

И затем дернем по primary key из NoSQL кластера инфу быстренько по каждому идшнику — это все равно на порядки быстрее джойна и фильтрации.

Да, конечно, чтобы это все так работало нужно СРАЗУ понять, какие запросы пойдут из приложения в NoSQL и подготовиться к ним через денормализацию.

В классческой БД трюк с быстрой выборкой диапазона атрибутов не провернешь — нужно создавать еще одно отношение и джойнить, что будет всегда медленнее, т.к. атрибуты в NoSQL хранятся отсортированными и в формате например skip list.

Лопатить надо только в том случае если данные, которые хочется записать в этот атрибут уже где-то есть… Но если вы хотите допонительно начать сохранять и использовать еще какие-то данные, то ничего лопатить не надо и именно в этом прелесть…

За Оракл не скажу, но добавить колонку в MySQL с сотней миллионов записей задача почти невыполнимая :))) а если еще и индекс захочется построить… то можно просто «уйти пожить» в это время…
философия подхода разная.

Когда с РСУБД перебирался на разработку под Lotus Domino испытывал некий разрыв шаблонов. В итоге пришёл (вычитал, додумал, etc) к следующему правилу: NoSQL базы оперируют целиком документами, а не полями.

Вот представьте себе некую компанию N, в которой хранятся бланки по форме F. Заполняли её днями/месяцами/годами. Спустя некоторое время выходит указ, согласно которому в бланк нужно добавить пару полей и одно поле удалить.

вот по философии РСУБД вы идёте в архив, поднимаете все заполненные бумаги и «перелопачиваете» их под новую форму бланка.
в философии NoSQL вы просто начинаете класть в архив бумаги заполненные по новому бланку.
Положить — пол дела. Главное обработать эти данные. И для корректной обработки нужна унифицированная форма. Иначе придется для старых бланков оставлять старую логику, для новых добавлять новую. И после связать это как-то вместе. А потом появятся еще изменения — и опять нам нужно разветвлять логику. В итоге со временем образуется эдакий раздутый монстр, который необходимо поддерживать из-за обратной совместимости.
Допустим тебе нужно выбрать состав корзины пользователя. Хранишь весь состав в атрибутах в одной строке и выдаешь одним быстрым запросом.

Аналогично — в атрибуты засовываются например записи пользователя в блоге или тэги. Ты выбираешь их из одной строки. Очень быстро и часто полезно в веб-приложениях. Другая логика разработки правда.
Это конечно здорово, но когда появляется желание посчитать, сколько же человек купили тот или иной продукт, начинаешь плакать кровавыми слезами.
Главное, что они его — купили :-)

Да, согласен, для аналитика отсутствие детерминированной целостной модели данных — кошмар. Но если попытаться договориться с продуктом, что точность нужна… ну не всегда… :-)
Не начинаешь, никто не говорит про использование NoSQL для каких-то аналитических задач… NoSQL для БЫСТРОЙ распределенной работы… но никак не для анализов…

не надо гвозди микроскопом забивать… ну разглядывать что-то в молоток тоже бесполезно…
Методы решения подобных задач зависят от конкретной СУБД и, как правило, решаются не сильно сложнее чем SELECT SUM(o.q) q FROM order o WHERE o.product_id=?.
атрибуты заданы в приложении

А если они задаются пользователем или из какого-то внешнего (по отношению к апп-сервер и субд) источника? И даже при жесткой (на данном этапе эволюции приложения) нам не нужно учить приложение читать/записывать не заданные атрибуты объекта — мы просто создаем объект без них. Пришли от пользователя незаполненные поля формы — не создаем атрибуты для них. Читаем объект из бд — создаем только то, что есть в записи. При добавлении какой-то новой функциональности, требующей новых атрибутов, нам не нужно ни изменять старую, ни добавлять «не задан» в бд, только научить новую обрабатывать «не задан» и для старых, и для новых записей. Кстати, ещё возникает дилемма в подобных случаях в SQL — как различить «отсутствует» и «не задан»? Null-то один! Ладно ещё если 0 не используется для числового поля. А если поле строковое?
Индексы нужно указать сразу, их должно быть не более — 5 на таблицу. Причем добавлять их в существующую таблицу — нельзя, нужно ее удалять, пересоздавать и перезаливать туда данные. Спокойный сон архитектору — обеспечен.

Могу ошибаться, но такое вроде только в Dynamo DB. В других «детях Динамо» — Cassandra, Voldemort, Riak — такого нет.
Амазон все обещает и обещает убрать этот «беспредел» — но это видимо потому, что Dynamo пока в Beta, либо есть какие нить технические сложности.

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

Amazon DynamoDB is designed to scale without limits. However, there are some initial limits in place on provisioned throughput:

US East (Northern Virginia) Region:

Per table – 40,000 read capacity units or 40,000 write capacity units
Per account – 80,000 read capacity units or 80,000 write capacity units
All Other Regions:

Per table – 10,000 read capacity units or 10,000 write capacity units
Per account – 20,000 read capacity units or 20,000 write capacity units
You can request an increase on any of these limits.
Интересующимся темой NoSQL вообще и Cassandra в частности рекомендую митап, который я организую в эту субботу — www.meetup.com/bigmoscow/events/135429192/.
К нам приедет русскоговорящий сотрудник DataStax, которому можно будет задать все свои вопросы, а также будут другие нескучные спикеры. Вход свободный, регистрация на сайте ивента обязательна.
>как в начале нынешнего столетия появились «NoSQL» продукты

ну сколько можно повторять не в начале нынешнего столетия а во второй половине прошлого ru.wikipedia.org/wiki/MUMPS и далее по списку
Я видимо неточно выразился, прошу прощения.

Хотел сказать, что реляционная теория во второй половине прошлого века была «математически обоснована», проверена — начали делать промышленный софт поддержки.

А другие разновидности систем хранения (объектные БД, графы и другие) — были предложены, но спали и активно проснулись в начале этого века, разбуженные вебом и мобильными технологиями.
нет, как раз то о чём я вам говорю а именно СУБД Cache — не находилось в состоянии сна и никем разбужена не была, и промышленный софт на базе её (тогда она называлась по другому это название уже прижилось в 80х) начали делать ещё до появления SQL и продолжают делать и поныне, понятное дело что с бумом веба — любая СУБД начала наращивать функциональность, но с точки зрения проверки временем, как раз у этой СУБД проверка более длительная чем у любой SQL базы, потому что появилась она раньше SQL и в своей сути, с тех пор не сильно изменилась (как не сильно, к примеру, изменилась суть языка C)
Круто, интересно. Я слышал про нее, но к сожалению руки не дошли пока.
увидел, моя ошибка
той же лажи с созданием индексов только сразу и ограничением на их количество в Cache также нет

и вообще считаю неверным интерпретировать данные исключительно в виде таблиц когда мы говорим о NoSQL — таблица в NoSQL — это всего лишь одна форма представления данных, не единственная не самая удобная и не самая функциональная — а просто одна из многих…
Согласен, слово таблица в контексте NoSQL, как и колонка — не совсем подходящие: отношения размытые, кортежей как бы нет, реляционная алгебра пьет пиво. Но я использовал их для простоты понимания темы. Коллеги прочитают доки и поймут.
Приятно услышать про Cache. Как же хочется написать наконец статейку и сравнить SAP и Ensemble/Cache изнутри :-)
если вы использовали и то и то изнутри «ручками» — то пишите статью обязательно!
Очень интересная публикация. Особенно после того как в прошлом году битрикс обещал сделать Highload Инфоблоки на NoSQL. Видимо не получилось…
Какая связь между этой публикацией и тем что у Битрикса что-то не получилось? (или просто пока не успелось)
Видимо связсь в том что публикация опубликована в блоге компании 1С-Битрикс
HighLoad инфоблоки вместе с поддержкой ORM выйдут вот скоро, в октябре, в 14 версии. Правда пока будет использоваться InnoDB HandlerSocket и либа к PHP — но планируем развивать перечень хранилищ.
В нашей mBaaS платформе используем и SQL (RDS) и NoSQL (MongoDB), просто они обслуживают разные задачи, например NoSQL используется как хранилище для Custom Objects API (типа key-value storage с заданной юзерами архитектурой) и для биллинга — там монга очень хорошо заняла своё место.
Разумно. Я тоже не пойму можно ли сейчас отказываться от SQL.

С другой стороны, если в проекте несколько серверов и нужно чтобы они могли запустится из образа в любом ДЦ и записать из любого места в локальную базу надежно… — тут может пригодиться NoSQL кластер как раз.
У себя в KeyCAPTCHA также используем связку NoSQL + SQL, на серверах генерации капч MongoDB, в SQL аналитические отчеты и веб-морда…
Разумно. Последнее время MongoDB прямо тренд какой-то. Видимо веб-системы станут гибридными — т.к. биллинг сложно реализовать на NoSQL :-)
Это можно считать тоже уже практически свершившийся факт…

Аналитику конечно НАМНОГО проще крутить в SQL, а вот быструю работу для конечного посетителя с возможностью горизонтального масштабирования (в случае необходимости) намного проще делать с помощью NoSQL решений.

Плохо только что пока нет каких-то серьезно-заметно-популярных гибридных фреймворков и CMS
Да вот, хочется увидеть решения, где можно вынести большие массивы данных в NoSQL и фигачить оттуда. А сложная реляционная модель, транзакции и т.п. — конечно пусть пока остается в приложении.

Таким образом можно держать центральный типа магазин в SQL, а корзины, партнерские витрины — на других серверах, континентах, работающие быстро с NoSQL.
Laravel — Mysql + Redis из коробки
В случае ruby on rails никакой проблемы в гибридных конфигурациях нет. В рамках одного приложения часть моделей в реляционках, часть в монго, например.
Symfony 2 с Doctrine ORM и Doctrine ODM.
Основная проблема у NoSQL в том, что у них часто нет транзакций (хотя есть и исключения). Хотя есть форк монги, который использует другую модель индексов и за счет этого у них есть и транзакции, и document-based locking (отсутствие, которого ещё одна проблема у монго).

Опять же монго предлагает делать транзакции по многоступенчатому механизму (в хелпе есть алгоритм), то есть, можно заменить, но все же это не совсем обычные транзакции.
Иногда достаточно изменить модель и транзакции не нужны становятся. Типичный пример использования транзакций вроде перевод с одного счета на другой, когда счета представлены отдельными записями в таблице Счета — поскольку две записи атомарно обработать не можем, то нужна транзакция. А ведь можно просто сделать таблицу Перевод, а состояние счета получать её редуцированием агрегацией. Мало того, обычно такая таблица всё равно делается.
>и для биллинга — там монга очень хорошо заняла своё место.

А как вы на монге транзакции реализуете? Как в хелпе описано? Или какой-то свой подход?
Специфического ничего не используем, всё согласно гайду.
MongoDB:
  • Типы данных — все необходимые;
  • Индексы можно добавлять и удалять в любой момент;
  • Максимальный размер одного документа — 16Мб;
  • Запросы могут использовать разные индексы для поиска и сортировки, но индексы могут быть составными;
  • Транзакций нет, но есть findAndModify.
А когда там в битриксе появятся highload инфоблоки, поддерживающие NoSql хранилища? Еще в том году обещали… :)
<зануда mode on>
Oracle RAC — видимо, дорого и сложно, тяжеловесно, да и как его раскидывать по разным материкам?
MySQL cluster — быстрый мастер-мастер, но много подводных камней и ограничений, типа хранения данных только в памяти, но для некоторых кейсов все же неплохо работает


MySQL Cluster уже давно может хранить данные на диске. А вот по разным материкам и даже датацентрам раскидать его даже не то что сложновато: работать-то он будет, но небезопасно и медленно. (Смотрим «Network Hardware» здесь)
</зануда mode off>
Only those users with full accounts are able to leave comments. Log in, please.