Комментарии 67
Насчет типов, зависит от языка и фронтенда самой базы. Если есть нормальная интроспекция, хватит одних бинарных. LevelDB (младший брат BigTable) как раз только бинарные ключи-значения и обслуживает. Но, например, Riak поверх нее уже сам приводит все в кортежи строк, чисел, списков и т. п.
Ну и денормализация — это тоже личный выбор архитектора. В реляционных базах тоже можно нахамить, чтобы летало.
Есть еще один подвох. No SQL создает ложное впечатление, что можно не знать SQL. Все просто же: положить/достать. Большая консистентная мапа, ура! А на самом деле, если не язык запросов, то уж правила Кодда знать как раз обязательно. Они не на пустом месте появились, мы можем делать вид, что работаем с произвольными кортежами, но в большинстве случаев данные представляют собой все те же таблицы и отношения между ними. Больше чем теоретики реляционных баз про это все не думал никто.
Ну и денормализация — это тоже личный выбор архитектора. В реляционных базах тоже можно нахамить, чтобы летало.
Есть еще один подвох. No SQL создает ложное впечатление, что можно не знать SQL. Все просто же: положить/достать. Большая консистентная мапа, ура! А на самом деле, если не язык запросов, то уж правила Кодда знать как раз обязательно. Они не на пустом месте появились, мы можем делать вид, что работаем с произвольными кортежами, но в большинстве случаев данные представляют собой все те же таблицы и отношения между ними. Больше чем теоретики реляционных баз про это все не думал никто.
Правильные выводы.
Но я бы дополнил их и плюсами в сторону NoSQL. Ведь для не малого количества задач, на NoSQL они ложатся как родные, а в реляционки никак.
Во вторых, все NoSQL предназначены для какого-то конкретного порядка CAP ереси ;).И для кадого из порядков выводы будут иметь совершенно различную окраску. Если внимательно смотреть на любой, даже банковский или космический проект — то можно найти удовлетворяющее допущение.
В третьих. Если в голове у акитекта с мегасуперопытом и образованием нет приязни с NoSQL — то и не нужно мучатся. Ведь в NoSQL данные часто не нормализуются, и вообще игнорируется большинство догм реляционок. По этому хороший и эффективный NoSQL это всегда ересь для опытного реляционщика. Совершенно другие паттерны, принципы. Самое главное не пытаться сделать NoSQL по принципам реляционок.
Но я бы дополнил их и плюсами в сторону NoSQL. Ведь для не малого количества задач, на NoSQL они ложатся как родные, а в реляционки никак.
Во вторых, все NoSQL предназначены для какого-то конкретного порядка CAP ереси ;).И для кадого из порядков выводы будут иметь совершенно различную окраску. Если внимательно смотреть на любой, даже банковский или космический проект — то можно найти удовлетворяющее допущение.
В третьих. Если в голове у акитекта с мегасуперопытом и образованием нет приязни с NoSQL — то и не нужно мучатся. Ведь в NoSQL данные часто не нормализуются, и вообще игнорируется большинство догм реляционок. По этому хороший и эффективный NoSQL это всегда ересь для опытного реляционщика. Совершенно другие паттерны, принципы. Самое главное не пытаться сделать NoSQL по принципам реляционок.
Согласен, плюсов у NoSQL решений немало. Взять к примеру гибкую структуру строки — пихай столько атрибутов, сколько нужно — и они еще автоматически хранятся отсортированными. И писать можно на любую ноду кольца серверов — идеальный мастер-мастер.
Но не покидает 2 ощущения:
— да этож набор memcached, только под другим соусом со всеми вытекающими
— это нужно ограниченному кругу зверских приложений, понимающих ограничения CAP — соцсети, некоторые виды электронной коммерции и т.п.
Но не покидает 2 ощущения:
— да этож набор memcached, только под другим соусом со всеми вытекающими
— это нужно ограниченному кругу зверских приложений, понимающих ограничения CAP — соцсети, некоторые виды электронной коммерции и т.п.
Ну зачем же зверские приложения… Практически любое web-приложение (кроме как раз электронной коммерции) не требует жесткой констистенции… Соответственно учитывая описанные преимущества по горизонтальному масштабированию БД (ведь очень хорошо если проект «стрельнит» и ему понадобится такое масштабирование) использование NoSQL именно в вебе ОЧЕНЬ и ОЧЕНЬ оправдано…
Можно говорить о том, что история это УЖЕ доказала…
Можно говорить о том, что история это УЖЕ доказала…
Никак не могу понять в чем профит от «пихай столько атрибутов, сколько нужно». Есть объект, у него есть атрибуты, атрибуты заданы в приложении. В БД не может быть каких-то еще атрибутов, кроме определенных — приложение не сможет их обработать. Может быть меньше, если часть из атрибутов не заданы (читай =null), но это надо учить приложение, создавая запись, отсекать пустые атрибуты. А это работа для программиста, усложнение архитектуры. Получается, колонки все-равно есть, только теперь схема данных хранится не в БД, а в приложении.
Именно про это и говорилось… Что захотелось изменить схему, изменил приложение и всё… А любая операция с SQL таблицами размером в десятки-сотни гигабайт занимает ОЙКАКМНОГО времени… а если еще и реплицируемая то нувообщелучшенеприкасаться…
После перехода на NoSQL ощутил почти экстаз от свободы с которой реализуются новые «хотелки»
После перехода на NoSQL ощутил почти экстаз от свободы с которой реализуются новые «хотелки»
Это не недостаток самой идеи реляционных баз данных. Сейчас крайне модно и даже никто не видит подвоха — создавать 2 конкурирующих сервера, решающих одну и ту же задачу — на языке вроде джавы, шарпа, который «взаимодействует» с БД. Вся цель его, всего лишь ослабить реляционную модель, бороться с ней, дублировать логику (писать классы, отражающие таблицы), гонять данные туда сюда с сериализацией, создать свой транзакционный механизм, который, конечно, слабее. Т.е. в любом проекте с БД, создается такой велосипедище, причем это считается правилом хорошего тона.
Думаю, сервер должен быть один. В теории. Не надо дублировать логику, дублировать схему. К сожалению, на мой взгляд реляционные СУБД для этого могли бы сгодиться, но они не доделаны. SQL хорош, но недостаточен. А процедурные языки унылы и неудобны. Бросили нас производители реляционных СУБД и гоняются только между собой за производительность некоторых операций.
Думаю, сервер должен быть один. В теории. Не надо дублировать логику, дублировать схему. К сожалению, на мой взгляд реляционные СУБД для этого могли бы сгодиться, но они не доделаны. SQL хорош, но недостаточен. А процедурные языки унылы и неудобны. Бросили нас производители реляционных СУБД и гоняются только между собой за производительность некоторых операций.
Хорошо сказали, пробрало до глубин :-)
Я не утверждал что это какой-то недостаток… Для пашки поля лучше использовать трактор, но для передвижения по трассе Porsche явно лучше…
В моем понимании «Одна БД», это какой-то такой гоночный трактор… круто конечно, но боюсь что не очень реализуемо, так как архитектурные принципы всё-таки различны…
В моем понимании «Одна БД», это какой-то такой гоночный трактор… круто конечно, но боюсь что не очень реализуемо, так как архитектурные принципы всё-таки различны…
> В моем понимании «Одна БД», это какой-то такой гоночный трактор…
> круто конечно, но боюсь что не очень реализуемо, так как архитектурные принципы всё-таки различны…
Подход NoSQL + SQL + ООП в рамках одной СУБД уже реализован.
А по поводу гоночного трактора… см. картинку здесь: habrahabr.ru/company/intersystems/blog/144306/
> круто конечно, но боюсь что не очень реализуемо, так как архитектурные принципы всё-таки различны…
Подход NoSQL + SQL + ООП в рамках одной СУБД уже реализован.
А по поводу гоночного трактора… см. картинку здесь: habrahabr.ru/company/intersystems/blog/144306/
не успел :)
Объектно-реляционный импеданс :-)
Hibernate OGM подойдёт?
Я скорее ощутил обратный эффект. Добавить колонку и в 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.
Еще пример — посты юзера в блоге. Можно ввести кросс-таблицу, а можно каждый факт поста отразить в атрибуте таблицы юзеров в виде $ИД-поста_таймстамп-поста и моментально одним запросом по ИД юзера их дернуть без джойнов, что очень помогает если связей много.
Еще пример — тэги. Объект связан с тэгами. Нужно построить облако тегов для всех объектов. Либо будем танцевать с джойнами — что при больших объемах равносильно смерти. Либо сразу денормализуем в одну запись о тэги информацию о связанных с ним объектах в атрибутах тэга:
железный авто_34 авто_3424 авто_7874 самолет_234232…
И затем дернем по primary key из NoSQL кластера инфу быстренько по каждому идшнику — это все равно на порядки быстрее джойна и фильтрации.
Да, конечно, чтобы это все так работало нужно СРАЗУ понять, какие запросы пойдут из приложения в NoSQL и подготовиться к ним через денормализацию.
В классческой БД трюк с быстрой выборкой диапазона атрибутов не провернешь — нужно создавать еще одно отношение и джойнить, что будет всегда медленнее, т.к. атрибуты в NoSQL хранятся отсортированными и в формате например skip list.
Лопатить надо только в том случае если данные, которые хочется записать в этот атрибут уже где-то есть… Но если вы хотите допонительно начать сохранять и использовать еще какие-то данные, то ничего лопатить не надо и именно в этом прелесть…
За Оракл не скажу, но добавить колонку в MySQL с сотней миллионов записей задача почти невыполнимая :))) а если еще и индекс захочется построить… то можно просто «уйти пожить» в это время…
За Оракл не скажу, но добавить колонку в MySQL с сотней миллионов записей задача почти невыполнимая :))) а если еще и индекс захочется построить… то можно просто «уйти пожить» в это время…
философия подхода разная.
Когда с РСУБД перебирался на разработку под Lotus Domino испытывал некий разрыв шаблонов. В итоге пришёл (вычитал, додумал, etc) к следующему правилу: NoSQL базы оперируют целиком документами, а не полями.
Вот представьте себе некую компанию N, в которой хранятся бланки по форме F. Заполняли её днями/месяцами/годами. Спустя некоторое время выходит указ, согласно которому в бланк нужно добавить пару полей и одно поле удалить.
вот по философии РСУБД вы идёте в архив, поднимаете все заполненные бумаги и «перелопачиваете» их под новую форму бланка.
в философии NoSQL вы просто начинаете класть в архив бумаги заполненные по новому бланку.
Когда с РСУБД перебирался на разработку под Lotus Domino испытывал некий разрыв шаблонов. В итоге пришёл (вычитал, додумал, etc) к следующему правилу: NoSQL базы оперируют целиком документами, а не полями.
Вот представьте себе некую компанию N, в которой хранятся бланки по форме F. Заполняли её днями/месяцами/годами. Спустя некоторое время выходит указ, согласно которому в бланк нужно добавить пару полей и одно поле удалить.
вот по философии РСУБД вы идёте в архив, поднимаете все заполненные бумаги и «перелопачиваете» их под новую форму бланка.
в философии NoSQL вы просто начинаете класть в архив бумаги заполненные по новому бланку.
Положить — пол дела. Главное обработать эти данные. И для корректной обработки нужна унифицированная форма. Иначе придется для старых бланков оставлять старую логику, для новых добавлять новую. И после связать это как-то вместе. А потом появятся еще изменения — и опять нам нужно разветвлять логику. В итоге со временем образуется эдакий раздутый монстр, который необходимо поддерживать из-за обратной совместимости.
Допустим тебе нужно выбрать состав корзины пользователя. Хранишь весь состав в атрибутах в одной строке и выдаешь одним быстрым запросом.
Аналогично — в атрибуты засовываются например записи пользователя в блоге или тэги. Ты выбираешь их из одной строки. Очень быстро и часто полезно в веб-приложениях. Другая логика разработки правда.
Аналогично — в атрибуты засовываются например записи пользователя в блоге или тэги. Ты выбираешь их из одной строки. Очень быстро и часто полезно в веб-приложениях. Другая логика разработки правда.
Это конечно здорово, но когда появляется желание посчитать, сколько же человек купили тот или иной продукт, начинаешь плакать кровавыми слезами.
Главное, что они его — купили :-)
Да, согласен, для аналитика отсутствие детерминированной целостной модели данных — кошмар. Но если попытаться договориться с продуктом, что точность нужна… ну не всегда… :-)
Да, согласен, для аналитика отсутствие детерминированной целостной модели данных — кошмар. Но если попытаться договориться с продуктом, что точность нужна… ну не всегда… :-)
Не начинаешь, никто не говорит про использование NoSQL для каких-то аналитических задач… NoSQL для БЫСТРОЙ распределенной работы… но никак не для анализов…
не надо гвозди микроскопом забивать… ну разглядывать что-то в молоток тоже бесполезно…
не надо гвозди микроскопом забивать… ну разглядывать что-то в молоток тоже бесполезно…
В СУБД Caché можно использовать аналитику в том числе и для NoSQL-приложений:
intersystems.ru/deepsee/index.html#m1
intersystems.ru/deepsee/index.html#m1
Методы решения подобных задач зависят от конкретной СУБД и, как правило, решаются не сильно сложнее чем
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, которому можно будет задать все свои вопросы, а также будут другие нескучные спикеры. Вход свободный, регистрация на сайте ивента обязательна.
К нам приедет русскоговорящий сотрудник DataStax, которому можно будет задать все свои вопросы, а также будут другие нескучные спикеры. Вход свободный, регистрация на сайте ивента обязательна.
>как в начале нынешнего столетия появились «NoSQL» продукты
ну сколько можно повторять не в начале нынешнего столетия а во второй половине прошлого ru.wikipedia.org/wiki/MUMPS и далее по списку
ну сколько можно повторять не в начале нынешнего столетия а во второй половине прошлого ru.wikipedia.org/wiki/MUMPS и далее по списку
Я видимо неточно выразился, прошу прощения.
Хотел сказать, что реляционная теория во второй половине прошлого века была «математически обоснована», проверена — начали делать промышленный софт поддержки.
А другие разновидности систем хранения (объектные БД, графы и другие) — были предложены, но спали и активно проснулись в начале этого века, разбуженные вебом и мобильными технологиями.
Хотел сказать, что реляционная теория во второй половине прошлого века была «математически обоснована», проверена — начали делать промышленный софт поддержки.
А другие разновидности систем хранения (объектные БД, графы и другие) — были предложены, но спали и активно проснулись в начале этого века, разбуженные вебом и мобильными технологиями.
нет, как раз то о чём я вам говорю а именно СУБД Cache — не находилось в состоянии сна и никем разбужена не была, и промышленный софт на базе её (тогда она называлась по другому это название уже прижилось в 80х) начали делать ещё до появления SQL и продолжают делать и поныне, понятное дело что с бумом веба — любая СУБД начала наращивать функциональность, но с точки зрения проверки временем, как раз у этой СУБД проверка более длительная чем у любой SQL базы, потому что появилась она раньше SQL и в своей сути, с тех пор не сильно изменилась (как не сильно, к примеру, изменилась суть языка C)
> Можно выбрать данные только по одному индексу
не знаете не говорите на хабре даже статья есть про bit-map индексы в Cache — чистый NoSQL habrahabr.ru/company/intersystems/blog/174657/
не знаете не говорите на хабре даже статья есть про bit-map индексы в Cache — чистый NoSQL habrahabr.ru/company/intersystems/blog/174657/
Это я про DynamoDB :-)
увидел, моя ошибка
той же лажи с созданием индексов только сразу и ограничением на их количество в Cache также нет
и вообще считаю неверным интерпретировать данные исключительно в виде таблиц когда мы говорим о NoSQL — таблица в NoSQL — это всего лишь одна форма представления данных, не единственная не самая удобная и не самая функциональная — а просто одна из многих…
и вообще считаю неверным интерпретировать данные исключительно в виде таблиц когда мы говорим о NoSQL — таблица в NoSQL — это всего лишь одна форма представления данных, не единственная не самая удобная и не самая функциональная — а просто одна из многих…
Согласен, слово таблица в контексте NoSQL, как и колонка — не совсем подходящие: отношения размытые, кортежей как бы нет, реляционная алгебра пьет пиво. Но я использовал их для простоты понимания темы. Коллеги прочитают доки и поймут.
Приятно услышать про Cache. Как же хочется написать наконец статейку и сравнить SAP и Ensemble/Cache изнутри :-)
Очень интересная публикация. Особенно после того как в прошлом году битрикс обещал сделать Highload Инфоблоки на NoSQL. Видимо не получилось…
Какая связь между этой публикацией и тем что у Битрикса что-то не получилось? (или просто пока не успелось)
HighLoad инфоблоки вместе с поддержкой ORM выйдут вот скоро, в октябре, в 14 версии. Правда пока будет использоваться InnoDB HandlerSocket и либа к PHP — но планируем развивать перечень хранилищ.
В нашей mBaaS платформе используем и SQL (RDS) и NoSQL (MongoDB), просто они обслуживают разные задачи, например NoSQL используется как хранилище для Custom Objects API (типа key-value storage с заданной юзерами архитектурой) и для биллинга — там монга очень хорошо заняла своё место.
Разумно. Я тоже не пойму можно ли сейчас отказываться от SQL.
С другой стороны, если в проекте несколько серверов и нужно чтобы они могли запустится из образа в любом ДЦ и записать из любого места в локальную базу надежно… — тут может пригодиться NoSQL кластер как раз.
С другой стороны, если в проекте несколько серверов и нужно чтобы они могли запустится из образа в любом ДЦ и записать из любого места в локальную базу надежно… — тут может пригодиться NoSQL кластер как раз.
У себя в KeyCAPTCHA также используем связку NoSQL + SQL, на серверах генерации капч MongoDB, в SQL аналитические отчеты и веб-морда…
Разумно. Последнее время MongoDB прямо тренд какой-то. Видимо веб-системы станут гибридными — т.к. биллинг сложно реализовать на NoSQL :-)
Это можно считать тоже уже практически свершившийся факт…
Аналитику конечно НАМНОГО проще крутить в SQL, а вот быструю работу для конечного посетителя с возможностью горизонтального масштабирования (в случае необходимости) намного проще делать с помощью NoSQL решений.
Плохо только что пока нет каких-то серьезно-заметно-популярных гибридных фреймворков и CMS
Аналитику конечно НАМНОГО проще крутить в SQL, а вот быструю работу для конечного посетителя с возможностью горизонтального масштабирования (в случае необходимости) намного проще делать с помощью NoSQL решений.
Плохо только что пока нет каких-то серьезно-заметно-популярных гибридных фреймворков и CMS
Да вот, хочется увидеть решения, где можно вынести большие массивы данных в NoSQL и фигачить оттуда. А сложная реляционная модель, транзакции и т.п. — конечно пусть пока остается в приложении.
Таким образом можно держать центральный типа магазин в SQL, а корзины, партнерские витрины — на других серверах, континентах, работающие быстро с 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>
MySQL Cluster уже давно может хранить данные на диске. А вот по разным материкам и даже датацентрам раскидать его даже не то что сложновато: работать-то он будет, но небезопасно и медленно. (Смотрим «Network Hardware» здесь)
</зануда mode off>
Oracle RAC — видимо, дорого и сложно, тяжеловесно, да и как его раскидывать по разным материкам?
MySQL cluster — быстрый мастер-мастер, но много подводных камней и ограничений, типа хранения данных только в памяти, но для некоторых кейсов все же неплохо работает
MySQL Cluster уже давно может хранить данные на диске. А вот по разным материкам и даже датацентрам раскидать его даже не то что сложновато: работать-то он будет, но небезопасно и медленно. (Смотрим «Network Hardware» здесь)
</зануда mode off>
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чем поможет архитектору «NoSQL» и… поможет ли?