Компания
241,32
рейтинг
12 сентября 2013 в 13:10

Разработка → Чем поможет архитектору «NoSQL» и… поможет ли?

В последнее время все больше говорят про «NoSQL» — прямо «модный» тренд образовался. «Технологию» начинают активно использовать известные авторитетные компании, в т.ч. в высоконагруженных проектах с немалыми объемами данных — и кто-то восхищается, а кто-то обливает себя бензином и факелом выпрыгивает с 35 этажа с криком: "SQL ACID forever!"


Причем о каком бы продукте не говорили, будь то MongoDB или Cassandra — нередко приходится наблюдать прямо таки религиозную восторженность и трепет, как будто речь идет о чем-то новом и священном.


А особенный трепет вызывают мелькающие в сети мозгораздирающие эскизы архитектур, типа кружочка из датацентров, работающих в «мастер-мастер репликации» на нескольких континентах:




Но… когда начинаешь серьезно использовать «новую» технологию в боевых проектах, понимаешь, откуда это все пошло, в чем причина тех или иных архитектурных решений: колечек датацентров и прочая мистика — формируется практическое и простое, «мурочное» понимание — которым хочется поделиться с коллегами, дабы не наделали архитектурных ошибок и не поплыли на плоту через океан. Об этом, в принципе, статья.


Чем же не устраивает старый, добрый ACID?


Ну вроде все предусмотрено — атомарность, согласованность, изоляция транзакций и надежность фиксации. Пробуй, строй, эксплуатируй. В ISO SQL прописали уровни изоляции транзакций — ну что еще не хватило для полного счастья, когда можно все детерминировать?

Что вызвало причину появления «CAP ереси» в стиле выбери только 2 из трех? :-)
  • согласованность данных
  • доступность
  • устойчивость к разделению



Ответ очевиден — бизнесу нужны новые, «сверхзвуковые» возможности хранилищ данных:
  • база должна быть всегда доступна для записи и чтения и кейсы типа сервер перезагружается, сеть упала — больно бьют по карману
  • интенсивный рост объемов данных и ужесточение требований к их доступности, в т.ч. из-за бурного развития всемирной сети — в одной базе данные ну они просто перестали помещаться
  • клиентов становится много в разных точках мира и нужно сохранить заказы как можно быстрее и т.п.
  • бурный рост веб-сервисов, появление мобильных устройств


Чем не устраивают «классические» кластера БД?


Из популярных:
  • Oracle RAC — видимо, дорого и сложно, тяжеловесно, да и как его раскидывать по разным материкам?
  • MySQL cluster — быстрый мастер-мастер, но много подводных камней и ограничений, типа хранения данных только в памяти, но для некоторых кейсов все же неплохо работает
  • galera cluster for mysql — да, честный мастер-мастер, пиши куда хочешь (но должен знать куда именно), но нет «устойчивости к разделению», может зависнуть при отсутствии кворума или сойти с ума, со скрипом восстанавливается при падении и тормозит при геораспределенном использовании, т.к. синхронно передает данные на все копии; да и нет шардинга данных между мастерами


А электронный бизнес требует и требует:
  • база должна быть доступна всегда, нельзя потерять заказ клиента или его корзину; даже если пропала синхронизация между нодами базы данных
  • база должна быть доступна везде (Европе и США), и, конечно, синхронизировать данные между копиями
  • база должна неограниченно масштабироваться при увеличении объема данных
  • база должна масштабироваться под нагрузку: на запись, на чтение

Понятно, что этот поток требований медленно, но верно вел к суициду… но

Ответ программистов — можно!


… Но если долго просить программистов сделать невозможное — они сделают!


Не все знают, что для полноценного программирования достаточно языка C, а для людей с чувством прекрасного можно излить душу и на C++ — так нет, под давлением бизнеса: «как можно программировать быстрее и чтобы все могли?» — родились технологии, которые на мощном железе сейчас даже уже работают: C#, java, python, ruby ...


Так вот, прошло не так много времени, как в начале нынешнего столетия появились «NoSQL» продукты и стало возможным:
  • писать на любой элемент кластера, всегда!
  • размещать элементы кластера на разных материках и читать с локальных!
  • вырубать любую ноду кластера и система не сойдет с ума!
  • добавлять ноды кластера когда душа пожелает, и это позволит масштабировать как запись, так и чтение!


Причем, судя по всему, кашу заварил Amazon с DynamoDB:
DynamoDB is the result of 15 years of learning in the areas of large scale non-relational databases and cloud services.

а затем идеи стали клонироваться в виде фейсбуковской Cassandra:
Apache Cassandra was developed at Facebook to power their Inbox Search feature by Avinash Lakshman (one of the authors of Amazon's Dynamo) and Prashant Malik. It was released as an open source project on Google code in July 2008.

И конечно без Google BigTable тут не обошлось.

Что же это за «серебряная пуля» такая?

А семь шапок сошьешь? И семь сошью...


При углубленном изучении «NoSQL» продуктов, а последний продукт с которым я плотно работал был Amazon DynamoDB (очень похожий на Apache Cassandra) — стали проявляться «скрытые подводные камни и ограничения», которые никак кроме как «платой за вседозволенность» не назовешь:

Писать можно на любую ноду кластера, а читать ...

А читать, по умолчанию, устаревшую неконсистентную информацию :-) А как вы хотели — информация же распространяется с ограниченной скоростью. Ну конечно можно поставить флажок и прочитать только что записанную информацию — но придется подождать-с.

Можно разместить ноды кластера на разных материках, но...

Но опять-таки, нужно знать, что информации нужно время — чтобы она разошлась по континентам и приложение должно уметь это обработать (видим переключение ответственности, блин… снова на программиста :-) ).

Можно выключать любую ноду кластера, рубить топором сетевые кабели, но...

Устойчивость к разделению кластера реализована за счет технологий, похожих на версионность — но периодически нужно будет запускать поиск рассогласований типа «Anti-entropy using Merkle trees».


Добавлять ноды кластера когда душа пожелает

Можно, но конфигурировать остальные ноды все-таки придется, иногда с ломом и паяльником.
А дальше — интереснее.

Ограничения Amazon DynamoDB


В наших проектах мы используем DynamoDB — передовое «NoSQL» решение от Amazon. Давайте рассмотрим его более подробно ниже.

Типов данных — откровенно мало

Число, строка, бинарные данные. Забудьте про DATETIME (их можно эмулировать таймстампом, но становится иногда не по себе).

Индексы добавлять можно, только… сразу

Индексы нужно указать сразу, их должно быть не более — 5 на таблицу. Причем добавлять их в существующую таблицу — нельзя, нужно ее удалять, пересоздавать и перезаливать туда данные. Спокойный сон архитектору — обеспечен.

Размер данных

Можно хранить любой объем данных, но… размер одной «строки таблицы» с именами и значениями «колонок» не должен превышать 64КБ. Правда число «колонок» не ограничивается.
И на одной ноде кластера (c одним значением основного индекса hash key) при наличии дополнительных индексов нельзя хранить больше 10ГБ, так то.
Видимо зря написал «колонок». В «NoSQL» нередко понятия схемы данных просто нет, поэтому в каждой «строке таблицы» могут быть разные «колонки» или «атрибуты».

Запросы...

Можно выбрать данные только по одному индексу (есть еще основной (hash key) индекс, но диапазонные выборки делать по нему нельзя — только константные). Отсортировать — только по одному индексу.
Забудьте про сложные «WHERE, GROUP BY», не говоря о подзапросах — «NoSQL» движки их просто эмулируют и могут выполнять очень медленно.
Можно выполнять более сложные выборки — но методом полного сканирования таблицы (пресловутый table scan) и затем поэлементной фильтрации результатов на серверной стороне, что и долго и дорого.

Транзакции — а что это?

Транзакции… иногда они нужны :-), а гарантируется лишь атомарное обновление отдельных сущностей (есть правда приятные плюшки с чтениями-инкрементами за одну операцию). Так что транзакции придется эмулировать — а то вы хотели, если данные «размазаны» по 20 серверам/датацентрам всего земного шарика?

Пляски с атрибутами

Нередко в «NoSQL», в т.ч. DynamoDB начинаю глумиться над основателями реляционной теории и создавать в строках ужасы типа:
user=john blog_post_$ts1=12 blog_post_$ts2=33 blog_post_$ts3=69…

где $ts1-3 — таймстампы публикаций пользователя в блог.

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

Выводы


1) Прежде чем выбирать для проекта «NoSQL» хранилище, вспомните причины появления франкенштейна подобного класса продуктов, что часто это не что иное, как набор «memcached» подобных серверов с надстроенной довольно простой логикой и, соответственно — сохранение данных и простые выборки будут, действительно, летать, а что-то посложнее… придется шаманить на стороне приложения.
2) Еще раз перечитайте теорему Брюера и найдите подвохи :-)
3) Внимательно посмотрите документацию по используемому продукту — особенно ограничения. Скорее всего вы встретите множество сюрпризов — и к ним нужно будет аккуратно подготовиться.
4) И посмотрите напоследок в глаза Кодду


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

Всем удачи!
Автор: @AlexSerbul
1С-Битрикс
рейтинг 241,32

Комментарии (67)

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

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

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

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

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

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

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

              В моем понимании «Одна БД», это какой-то такой гоночный трактор… круто конечно, но боюсь что не очень реализуемо, так как архитектурные принципы всё-таки различны…
          • +3
            Я скорее ощутил обратный эффект. Добавить колонку и в SQL мгновенная операция. Переименовать колонку/аттрибут — в SQL мгновенно, в noSQL нужно лопатить все записи. Изменить формат записи (например, решили хранить содержимое поля в апперкейсе) — в SQL долго, зато никто не увидит промежуточный результат, пока операция не закончится; в noSQL также придется лопатить все записи, только при этом писать map-reduce скрипт, и пока он будет работать, клиенты будут видеть записи в обоих форматах. Останавливать сервис на время обновления? В чем гибкость?
            • 0
              Добавить колонку и в SQL мгновенная операция.
              — а если в таблице миллионы записей, все станет колом на полчаса? И эта одна колонка попадет во все кортежи, хотя она нужна может нескольким или вообще одному. NoSQL скорее хранит «колонки» компактно и займут они места столько, сколько нужно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Могу ошибаться, но такое вроде только в Dynamo DB. В других «детях Динамо» — Cassandra, Voldemort, Riak — такого нет.
    • +1
      Амазон все обещает и обещает убрать этот «беспредел» — но это видимо потому, что 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.
  • +2
    Интересующимся темой NoSQL вообще и Cassandra в частности рекомендую митап, который я организую в эту субботу — www.meetup.com/bigmoscow/events/135429192/.
    К нам приедет русскоговорящий сотрудник DataStax, которому можно будет задать все свои вопросы, а также будут другие нескучные спикеры. Вход свободный, регистрация на сайте ивента обязательна.
  • 0
    >как в начале нынешнего столетия появились «NoSQL» продукты

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

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

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

    не знаете не говорите на хабре даже статья есть про bit-map индексы в Cache — чистый NoSQL habrahabr.ru/company/intersystems/blog/174657/
    • +1
      Это я про DynamoDB :-)
      • 0
        увидел, моя ошибка
      • 0
        той же лажи с созданием индексов только сразу и ограничением на их количество в Cache также нет

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

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

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

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

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

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

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


    MySQL Cluster уже давно может хранить данные на диске. А вот по разным материкам и даже датацентрам раскидать его даже не то что сложновато: работать-то он будет, но небезопасно и медленно. (Смотрим «Network Hardware» здесь)
    </зануда mode off>

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка