Comments 96
Если вдруг такое случится и станет не хватать скорости или функциональности MongoDB — ничто не помешает использовать MySQL в качестве кэширующей прослойки / индекса для данных — один раз настроить и забыть.
Все более менее хорошо (есть пара дискуссионных мест, но нет времени на холливар), но последняя фраза бред какой-то… хотите использовать кеширующий индекс — используйте тогда сфинкс.
тут есть много разных предложений на дороботку по производительности. У Монги один недостаток — это общий лок на коллекцию.
«хотите использовать кеширующий индекс — используйте тогда сфинкс»
Последняя фраза относится именно к нашей ситуации. Я не представляю как бы мы мигрировали с монги обратно на mysql, но вполне допускаю что какие то функции mysql нам понадобятся.
Сфинкс уже используем и в принципе я буду до последнего стараться работать именно с ним.
Последняя фраза относится именно к нашей ситуации. Я не представляю как бы мы мигрировали с монги обратно на mysql, но вполне допускаю что какие то функции mysql нам понадобятся.
Сфинкс уже используем и в принципе я буду до последнего стараться работать именно с ним.
У Монги один недостаток — это общий лок на коллекцию.
В версии 2.8 лок будет на документ. Для экстремалов есть патч начиная с версии 2.7.3.
Я, если честно, не считаю это недостатком, это скорее упущение, и скорее намеренное. Они не делали сразу лок на документ из за нехватки ресурсов и времени, да и возможно не нужно было столько операций в секунду в тот момент.
Могу ошибиться, но разве MyISAM не блокируется на таблицу (читай как коллекцию)?
>В версии 2.8 лок будет на документ.
хорошая новость… но мы ушли с версии где-то 2.3
>Могу ошибиться, но разве MyISAM не блокируется на таблицу (читай как коллекцию)?
а кто-то из тех, кому нужна производительность, пользуется MyISAM?
хорошая новость… но мы ушли с версии где-то 2.3
>Могу ошибиться, но разве MyISAM не блокируется на таблицу (читай как коллекцию)?
а кто-то из тех, кому нужна производительность, пользуется MyISAM?
С версии 2.3 много чего изменилось. Попробуйте. Может и понравится.
На счет MyISAM. Я как бы о том что в современном мире лок на таблицу применяется и ни кто это не ставит в упрек MySQL. А на счет производительности. Разве MyISAM не быстрее на чтение? Разные задачи, разные движки, разные решения.
Да и вообще все это лирика и холивар без хорошей конкретизации задачи.
На счет MyISAM. Я как бы о том что в современном мире лок на таблицу применяется и ни кто это не ставит в упрек MySQL. А на счет производительности. Разве MyISAM не быстрее на чтение? Разные задачи, разные движки, разные решения.
Да и вообще все это лирика и холивар без хорошей конкретизации задачи.
> Разве MyISAM не быстрее на чтение?
если его постоянно не лочить :)
>Да и вообще все это лирика и холивар без хорошей конкретизации задачи.
что верно, то верно
если его постоянно не лочить :)
>Да и вообще все это лирика и холивар без хорошей конкретизации задачи.
что верно, то верно
> Разве MyISAM не быстрее на чтение? Разные задачи, разные движки, разные решения.
Это давно не так.
MyISAM сейчас используют либо legacy приложения, либо для очень специфических случаев.
Это давно не так.
MyISAM сейчас используют либо legacy приложения, либо для очень специфических случаев.
Лок на коллекцию — это особенность, с которой надо просто научиться жить — читать могут сразу все, писать только один. Для снижения очередей записи помогает грамотно подобранный шардинг и архитектура базы. В нашей системе скорость записи до 200-1000 операций записи в секунду в одну коллекцию. Подходящий шард-ключ и денормализация данных нивелируют однопоточную запись. С выходом 2.8, возможно, получится отказаться от некоторых велосипедов.
А какие проблемы с этим локом? Один фиг коллекция на моем железе обновляется со скоростью примерно 1000 в секунду. Разве этого мало? Постгрес без лока на таблицу обрабатывает гораздо меньше, и толку спрашивается?
Слово durability ни о чем не говорит? Запись в /dev/null вообще по скорости порвет всех.
Во-первых как durability связано с локом? Во-вторых у меня включено журналирование, так что с durability у меня все равно хорошо.
Странно что вы не понимаете:
Время единичной записи на диск порядка 8 мс на обычном диске. Последовательная запись делается быстрее, но до 1000 раз в секунду далеко. И то если жестко оптимизировать запись.
При этом write ahead log требует двух операций записи — в лог и на диск.
Космические скорости дотигаются тем, что монга не пишет на диск, а говорит ОК как только запрос получен. То есть в лог еще ничего не записано. Запросы из-за лока выстраиваются а очередь, а приложение считает что оно реально пишет 1000 документов в секунду.
В субд с durability нельзя вернуть из субд ОК, пока не произошла запись лога на диск. Это аналогично journaled write concern в монге. Для честного сравнения поставь journaled и сделай пару индексов. 1000 в секунду упадет до 50, зато появится гарантия что запись действительно записала.
Кстати в sql server, используя bulk insert с коммитом по 5000 записей и tablock мне легко удавалось делать по 20,000 записей в секунду в heap table без индексов. Это почти такой же сценарий, как предлагает mongo по умолчанию. Так чтобмонга завидный тормоз в этом плане.
Время единичной записи на диск порядка 8 мс на обычном диске. Последовательная запись делается быстрее, но до 1000 раз в секунду далеко. И то если жестко оптимизировать запись.
При этом write ahead log требует двух операций записи — в лог и на диск.
Космические скорости дотигаются тем, что монга не пишет на диск, а говорит ОК как только запрос получен. То есть в лог еще ничего не записано. Запросы из-за лока выстраиваются а очередь, а приложение считает что оно реально пишет 1000 документов в секунду.
В субд с durability нельзя вернуть из субд ОК, пока не произошла запись лога на диск. Это аналогично journaled write concern в монге. Для честного сравнения поставь journaled и сделай пару индексов. 1000 в секунду упадет до 50, зато появится гарантия что запись действительно записала.
Кстати в sql server, используя bulk insert с коммитом по 5000 записей и tablock мне легко удавалось делать по 20,000 записей в секунду в heap table без индексов. Это почти такой же сценарий, как предлагает mongo по умолчанию. Так чтобмонга завидный тормоз в этом плане.
Не правда, монга говорит ОК только после того, как данные записанны и в память и в лог. Файлы данных обновляются отложенно и восстанавливаются из лога в случае краша. Таким образом монга обеспечивает durability. Более того такая схема никак не мешает выкинуть лок на документ, он вообще никак со схемой с логами и файлами данных не связан. Большая скорость обновления обеспечивется высокой скоростью последовательной записи на диск.
и ваша не правда. Монга говорит ОК в зависимости от того, как вы ее попросите, она может сказать ОК как только получила запрос. И еще не факт, что ваш запрос отработает. А может отдать ОК, когда данные лягут на диск. И еще много каких вариантов, включая ваш.
По умолчанию монга себя так не ведет. Даже если вы включили журналирование, то journaled write concern автоматически не включится. Вы включите journaled write concern и посмотрите на реальную скорость записи.
Логи кстати во всех СУБД линейно пишут, так что монга тут не инноватор, и даже далеко не впереди по скорости. Вся скорость записи монги это обман потребителя. Этот обман приводит иногда к удивительным багам.
Что касается локов на документ, то посмотрим как их сделают. Особо интересно как они локи на документ совместят с индексами.
Логи кстати во всех СУБД линейно пишут, так что монга тут не инноватор, и даже далеко не впереди по скорости. Вся скорость записи монги это обман потребителя. Этот обман приводит иногда к удивительным багам.
Что касается локов на документ, то посмотрим как их сделают. Особо интересно как они локи на документ совместят с индексами.
тут важно уточнить вот какой момент — использование mmap. Редко какой SQL сейчас его не использует в продакшене. То есть транзакция коммитится тоже не на диск, а в память. Но попадание на диск гарантирует ОС, то есть потеря данных может произойти только в случае краша оси. А если включить в SQL сброс на диск по каждой транзакции, то SQL тоже ничего волшебного не покажет. Хорошо бы дождаться 2.8 с локом на документ. И посмотреть ее производительность. Не на синтетике, а на реальной нагрузке, где есть и чтения, и запись
SQL Server например не использует, ибо небуферизированная запись на диск быстрее mmap. На *nix по скорости mmap+fsync сравнимы с небуферизированной записью. Тем не менее во всех субд используется именно гарантированная запись логов на диск, с использованием fsync например, даже в Монге. Но если каждый клиент начнет ждать записи на дист, то 1000 записей в секунду резко превратятся в 50 записей в секунду. В РСУБД тоже есть способы отложить запись на диск и получить «космическую» скорость, но это необходимо крайне редко. А durability необходима почти всегда.
Последовательная запись да, профит не значителен. А при рандомных апдейтах? Мы же говорим не только о записи, но и об обновлении тоже?
Лог всегда пишется последовательно, а запись данных на диск в этом случае вообще можно откладывать до вытеснения данных из памяти (если лог не перетирается и не урезается). Проблема будет только в том, что восстановление после сбоя в таком случае будет долгим.
Все-то вы правильно говорите) Но ведь головка еще должна доехать до того места, где этот лог находится. Диск же не только лог пишет. Что-то еще читается, а основное время уходит на перемещение головки. Наш разговор превращается в препирательство. Я не против SQL, он хорош. Я не пропагандирую делать все подряд на монге, она имеет свои особенности. Но для определенных задач монга имеет определенный профит. В нашем случае монга себя полностью оправдывает — шардинг из коробки, запись на уровне памяти, поддержка неподтвержденной записи. Есть данные, важность которых не высока, они пишутся в режиме w=0,j=0, чтобы не тратить время приложения на ожидание подтверждения записи. Скорость потока данных варьируется в зависимости от времени суток от 200 до 1000 документов в секунду. В данный момент статистика на монге такая: query — 5.5K/sec, update — 1.6K/s, insert — 800/sec. Кластер состоит из 4 шардов. В случае с SQL пришлось бы вопрос шардинга брать на сторону приложения, лично я не видел нормального шардинга на опенсорсном SQL.
Монга точно также пишет лог, как и другие СУБД. Она только клиенту может отвечать не строго после того как лог записан, а раньше этого момента. Ваши рассуждения о головке к чему?
Шардинг это очень простая вещь. Я бы не называл это преимуществом монги, монга лишь делает это прозрачно для пользователя. Но никаких достижений оно не несет. Да и потребность в шардинге во взрослых субд гораздо ниже. База на несколько ТБ для обычного SQL Server на одной машине вполне нормальное явление. Монге для такого объема понадобится 100500 шард с общим объемом памяти гораздо больше 1 ТБ, и с суммарной стоимостью серверов, на порядок превышающий стоимость железа под SQL Server.
Если у вас есть данные, важность которых не высока, то вы можете в приложении складывать их в очередь и струячить в базу пачками по несколько тысяч штук или по таймауту. И неважно какая база у вас будет. Почти любая СУБД сможет в таком сценарии выдать десятки тысяч записей в секунду, а приложение не будет ничего ждать.
Шардинг это очень простая вещь. Я бы не называл это преимуществом монги, монга лишь делает это прозрачно для пользователя. Но никаких достижений оно не несет. Да и потребность в шардинге во взрослых субд гораздо ниже. База на несколько ТБ для обычного SQL Server на одной машине вполне нормальное явление. Монге для такого объема понадобится 100500 шард с общим объемом памяти гораздо больше 1 ТБ, и с суммарной стоимостью серверов, на порядок превышающий стоимость железа под SQL Server.
Если у вас есть данные, важность которых не высока, то вы можете в приложении складывать их в очередь и струячить в базу пачками по несколько тысяч штук или по таймауту. И неважно какая база у вас будет. Почти любая СУБД сможет в таком сценарии выдать десятки тысяч записей в секунду, а приложение не будет ничего ждать.
Да, в шардинге монги нет никакого технологического прорыва. Но он снимает этот вопрос с пользователя. В нашем случае общий объем базы 15Тб, суммарный объем потребляемой памяти в пределах 250Гб с учетом кеша, шардов, как я уже говорил, 4.
Объем данных какой? 15 для монги может означать, что базу не шринкали никогда, а живых данных там от силы 100гб.
На SQL Server с 4 дисками из ваших шардов и 250гб памяти у меня будет все летать. А разницы в цене серваков хватит на лицензии SQL Server и еще в отдохнуть съездить. Терабайтные базы на пятикратно более слабом железе у меня работали.
На SQL Server с 4 дисками из ваших шардов и 250гб памяти у меня будет все летать. А разницы в цене серваков хватит на лицензии SQL Server и еще в отдохнуть съездить. Терабайтные базы на пятикратно более слабом железе у меня работали.
мне всё-таки кажется, что шарды нужны больше не для увеличения объема данных, а для распараллеливания запросов (чтения и записи)
Во взрослых субд это делается просто добавлением дисков.
я про ограничение процессора, а не дисков.
Упереться в процессор — надо постараться. Индексы и материализованные представления позволяют все вычисления перенести на стадию записи и даже на 15ТБ можно делать агрегирующие запросы за доли секунды.
В монге такое в принципе невозможно. Там любой запрос, который затрагивает хотя бы 10% документов уже нужно делать через map-reduce, который ну ооооочень небыстрый.
В монге такое в принципе невозможно. Там любой запрос, который затрагивает хотя бы 10% документов уже нужно делать через map-reduce, который ну ооооочень небыстрый.
Ураа, продолжение холивара.
Третий вариант — самый гибкий, но от него почти сразу отказались, так как нужны были сортировки и фильтрация по названиям, и для этого все равно пришлось бы делать что-то аналогичное варианту 1 или 2.
Ехал постгрес через постгрес. Тем более что в 9.4 нормальная работа jsonb появилась с индексами и печеньками.
Я тоже, когда услышал про поддержку json — порадовался за них, мне кажется это хороший вектор для развития. В нашем случае это одна из вещей, которой сильно не хватало.
До JSON'а был hstore, он тоже умел в индексы.
И индексы к нему тоже есть разные, под разные типы выборок: github.com/akorotkov/hstore_ops
Ну, в таком случае и за мускуль можно порадоваться, Света Смирнова научила его работать с JSON
blog.ulf-wendel.de/2013/mysql-5-7-sql-functions-for-json-udf/
жаль что не нативные, но и в этом тоже есть свой плюс.
blog.ulf-wendel.de/2013/mysql-5-7-sql-functions-for-json-udf/
жаль что не нативные, но и в этом тоже есть свой плюс.
С монго вырастают требования к серверу. Сами разработчики рекомендуют, как минимум, 3 сервера для создания кластера.
На мой взгляд, монго интересно рассматривать только в виде кластера. Рекомендации разработчиков о 3 серверах наверняка связаны в обеспечением отказоустойчивости?
>Сами разработчики рекомендуют, как минимум, 3 сервера для создания кластера.
с Кассандрой не путаешь? которая разрабатывалось как чисто кластерное решение с дублированием информации.
и воввсе не обязательно отказоустойчивость… Монга интересна сама по себе и как кластеное, и как серверное решение.
с Кассандрой не путаешь? которая разрабатывалось как чисто кластерное решение с дублированием информации.
и воввсе не обязательно отказоустойчивость… Монга интересна сама по себе и как кластеное, и как серверное решение.
3 ноды это минимум для того, чтоб отказоустойчивый replica set умел правильно определять лидера. Технически это может быть 2 настоящих узла и один легкий (арбитр).
>> В результате, начав с нуля (уже в качестве стартапа) разработку на Python в 2013 году, мы, правильно выбрав инструменты (одним из которых была MongoDB), за квартал сделали больше, чем раньше делали за два года.
Это называется опыт, MongoDB здесь не является решающим фактором.
Это называется опыт, MongoDB здесь не является решающим фактором.
Ждем через год-другой статьи «Почему вы никогда не должны использовать MongoDB» (:
уже был такой доклад на Highload++
Ждал описания того, как теперь всё сделано на mongodb и почему это лучше, чем mysql
UFO just landed and posted this here
PostgreSQL хороший выбор, да, но за 11 лет работы с РСУБД я немного от них устал, по этому до рассмотрения PostgreSQL дело просто не дошло.
А с какими ещё РСУБД вам приходилось работать? :)
Всё-таки PostgreSQL — это не просто реляционная, это объектно-реляционная СУБД. И мне достаточно сложно представить, как она может выпасть из рассмотрения.
Всё-таки PostgreSQL — это не просто реляционная, это объектно-реляционная СУБД. И мне достаточно сложно представить, как она может выпасть из рассмотрения.
С разными приходилось, сейчас вот приходится работать firebird. Но наверно 99% времени я работал с MySQL.
Если сравнивать PostgreSQL и MongoDB, то для меня проще работать с монгой — это наверно основная причина. Мне не нужно думать — какие данные пойдут в json, а какие в основные поля таблицы, не придется думать о миграции полей из json в поля таблицы и обратно. Не придется вообще работать с таблицами, мне нравится, что у монги есть полноценный яваскрипт в консоли, что мне не придется думать об sql injection, если я отдам какие то модули на аутсорс. Как то так.
Если сравнивать PostgreSQL и MongoDB, то для меня проще работать с монгой — это наверно основная причина. Мне не нужно думать — какие данные пойдут в json, а какие в основные поля таблицы, не придется думать о миграции полей из json в поля таблицы и обратно. Не придется вообще работать с таблицами, мне нравится, что у монги есть полноценный яваскрипт в консоли, что мне не придется думать об sql injection, если я отдам какие то модули на аутсорс. Как то так.
У SQL и noSQL разные сферы применения. Если в приложении отсутствуют или минимальны связи между сущностями, то зачем пытаться притянуть к такому приложению реляционную базу данных. Плюс у монги достаточно удобный шардинг из коробки, организация которого практически исключает единую точку отказа, если кластер построен по всем рекомендациям.
UFO just landed and posted this here
В любом правиле есть исключения. Представьте систему, в которой есть только две сущности — сообщение и автор. И сообщений, как и авторов, очень много (например, миллиарды). Какой смысл в такой системе от использования SQL? И можно ли такую систему считать «микроприложением»?
Какой смысл в такой системе от использования SQL?
может в согласованности данных в БД?
приложение не предусматривает удаление какой-либо информации.
1. проверили наличие автора
2. сохранили сообщение
какую проблему согласованности ожидать?
Я изначально обозначил свою позицию в этом вопросе — у SQL своя зона применения, у noSQL своя. Если у приложения нет необходимости в преимуществах SQL, а преимущества noSQL делают его более выгодным кандидатом при выборе БД, то зачем усложнять себе жизнь?
Я никому не предлагаю заменить SQL на noSQL. Они оба хороши по-своему
1. проверили наличие автора
2. сохранили сообщение
какую проблему согласованности ожидать?
Я изначально обозначил свою позицию в этом вопросе — у SQL своя зона применения, у noSQL своя. Если у приложения нет необходимости в преимуществах SQL, а преимущества noSQL делают его более выгодным кандидатом при выборе БД, то зачем усложнять себе жизнь?
Я никому не предлагаю заменить SQL на noSQL. Они оба хороши по-своему
Автор удалился между п1 и п2.
А еще интереснее если надо сделать не одну запись, а несколько, и в любой момент может отвалится часть записей. Если вы занимаетесь денормализацией, то запись в несколько коллекций — нередкое явление.
Можно попробовать обойти проблему через map-reduce индексы, но они, сука, тоже неконсистентны, то есть нельзя принимать решения на основании данных из индекса, ибо данные уже мог кто-то записать, а индекс еще нифига не обновился.
В комментариях к статье habrahabr.ru/post/231703/ как раз есть пример с продажей билетов, который монге не по зубам.
А еще интереснее если надо сделать не одну запись, а несколько, и в любой момент может отвалится часть записей. Если вы занимаетесь денормализацией, то запись в несколько коллекций — нередкое явление.
Можно попробовать обойти проблему через map-reduce индексы, но они, сука, тоже неконсистентны, то есть нельзя принимать решения на основании данных из индекса, ибо данные уже мог кто-то записать, а индекс еще нифига не обновился.
В комментариях к статье habrahabr.ru/post/231703/ как раз есть пример с продажей билетов, который монге не по зубам.
Автор удалился между п1 и п2.
тогда читаем первую строчку — приложение не предусматривает удаление какой-либо информации.
то есть автор удалиться не может
данные уже мог кто-то записать, а индекс еще нифига не обновился.
write concern закрутить покрепче, ну или кеш
продажные, читай транзакционные, сайты на нетранзакционной базе делать — зачем усложнять себе жизнь?
почему все так пытаются приладить монгу там, где делать этого не стоит?
map-reduce индексы в фоне обновляются насколько я понимаю, writeconcern им не помогает, зато роняет быстродействие монги на порядок (это я вживую видел).
Вопрос согласованности данных актуален не только при работе с деньгами.
Вопрос согласованности данных актуален не только при работе с деньгами.
Да, я не уточнил, имел в виду обычные индексы. И вообще к индексам в монге надо подходить с умом. Добавление 2 индексов (1 по одному полю, другой по трем) снизило скорость вставки с 11 тысяч до 500
ключевым словами были транзакционные и нетранзакционные. Без упора на деньги
«Желание «попробовать что-то новое» было выше, чем «сделать эффективно»?»
Нет — мне кажется в статье видно, что еще до знакомства с MongoDB мы перешли на сходный с монгой принцип хранения данных. Монга была не чем то новым, а скорее ответом на наши потребности.
Нет — мне кажется в статье видно, что еще до знакомства с MongoDB мы перешли на сходный с монгой принцип хранения данных. Монга была не чем то новым, а скорее ответом на наши потребности.
единая точка отказа — это mongos
> Еще одним из, как мне кажется, правильных решений был выбор админки, которая позволяла редактировать объекты любой вложенности
Как называется админка, если не секрет?
Как называется админка, если не секрет?
В качестве API: python-eve
Фронтенд: backbone-forms — большой плюс — поддержка вложенных форм.
Выглядит все это как то так:
Фронтенд: backbone-forms — большой плюс — поддержка вложенных форм.
Выглядит все это как то так:
Из требований не увидел ровным счётом НИЧЕГО, что просто требовало бы NoSQL.
Ребята, вы занимаетесь натягиванием задач на технологию, а не применением технологии для решения задачи! Подрастёте — появится понимание, что игры в новомодные баззворды — удел студентов с «бесконечным» временем, а в реальной работе нужны чёткие, проверенные решения.
И главное, кого и в чём вы хотите убедить своей статьёй? Вы СЕБЕ хотите доказать, что не ошиблись? Это называется патологическое враньё, от него нужно лечиться.
Ребята, вы занимаетесь натягиванием задач на технологию, а не применением технологии для решения задачи! Подрастёте — появится понимание, что игры в новомодные баззворды — удел студентов с «бесконечным» временем, а в реальной работе нужны чёткие, проверенные решения.
И главное, кого и в чём вы хотите убедить своей статьёй? Вы СЕБЕ хотите доказать, что не ошиблись? Это называется патологическое враньё, от него нужно лечиться.
Сложно комментировать, когда за тебя уже все решили и до кучи еще и диагноз поставили, но я всетаки попробую.
Статья называется «Почему мы выбрали MongoDB».
Выбор основан не столько на требованиях, сколько на удобстве разработки в соответствии с требованиями.
Эту же задачу можно решить вообще без использования SQL/NoSQL решений, но зачем? Вопрос в удобстве, нам удобнее так и в статье описывается почему.
Статья называется «Почему мы выбрали MongoDB».
Выбор основан не столько на требованиях, сколько на удобстве разработки в соответствии с требованиями.
Эту же задачу можно решить вообще без использования SQL/NoSQL решений, но зачем? Вопрос в удобстве, нам удобнее так и в статье описывается почему.
Вы же сами себе противоречите в одном и том же предложении!
> Выбор основан не столько на требованиях, сколько на удобстве разработки в соответствии с требованиями.
Так учитываются «требования» или нет??
Логически рассудите: требование — «хранить разнородные записи». Решение — «берём РСУБД и создаём таблицы» — потому что это классическое, проверенное временем решение на ТЫСЯЧАХ систем. Вы от него отказываетесь. Причина? «Мне не нужно думать — какие данные пойдут в json, а какие в основные поля таблицы, не придется думать о миграции полей из json в поля таблицы и обратно. Не придется вообще работать с таблицами, мне нравится, что у монги есть полноценный яваскрипт в консоли, что мне не придется думать об sql injection...» (к слову, о половине этой белиберды я вообще не думаю — просто решаю задачу)
Другими словами, это даже не «технический выбор», а чисто субъективное «мне не надо думать» (хотя я не понимаю, как можно «не думать» там, где как раз всё ядро системы!). Сунете вы данные в Mongo или SQL, всё-равно придётся заботиться о многих вещах, от консистентности данных до производительности, балансировки нагрузки и шифрования.
Кратко говоря, вы даже не выбирали, а просто «мне так удобно» и бац — поставили MongoDB! И _это_ заслуживало отдельной статьи??? :))) Я потому и написал «диагноз» (разве он не верен?), что ДАЖЕ если у вас были какие-то технические соображения, в этой многословной статье я их не увидел.
«Технический выбор» — это когда:
«Мы сделали реляционные таблицы (схема), в нашей задаче нужно выбрать список бла-бла… получилось вот такое решение (SQL запрос/ORM, объекты) с такими затратами по памяти/времени и вот такими перспективами под будущие нужды. А теперь мы перенесём это в NoSQL — получилась вот такая выборка, вот на столько стало МЕНЬШЕ(?) кода/времени/памяти и вот так увеличилась гибкость по расширению системы». Если бы я это прочёл, я бы выкинул нафик все свои базы, побрил голову (так принято) и пошёл к вам в ученики. :) Но ничего этого я не увидел, поэтому и написал своё мнение: ваш выбор сугубо индивидуальный и не показывает НИКАКИХ преимуществ, почему нужно делать решение именно на NoSQL.
> Выбор основан не столько на требованиях, сколько на удобстве разработки в соответствии с требованиями.
Так учитываются «требования» или нет??
Логически рассудите: требование — «хранить разнородные записи». Решение — «берём РСУБД и создаём таблицы» — потому что это классическое, проверенное временем решение на ТЫСЯЧАХ систем. Вы от него отказываетесь. Причина? «Мне не нужно думать — какие данные пойдут в json, а какие в основные поля таблицы, не придется думать о миграции полей из json в поля таблицы и обратно. Не придется вообще работать с таблицами, мне нравится, что у монги есть полноценный яваскрипт в консоли, что мне не придется думать об sql injection...» (к слову, о половине этой белиберды я вообще не думаю — просто решаю задачу)
Другими словами, это даже не «технический выбор», а чисто субъективное «мне не надо думать» (хотя я не понимаю, как можно «не думать» там, где как раз всё ядро системы!). Сунете вы данные в Mongo или SQL, всё-равно придётся заботиться о многих вещах, от консистентности данных до производительности, балансировки нагрузки и шифрования.
Кратко говоря, вы даже не выбирали, а просто «мне так удобно» и бац — поставили MongoDB! И _это_ заслуживало отдельной статьи??? :))) Я потому и написал «диагноз» (разве он не верен?), что ДАЖЕ если у вас были какие-то технические соображения, в этой многословной статье я их не увидел.
«Технический выбор» — это когда:
«Мы сделали реляционные таблицы (схема), в нашей задаче нужно выбрать список бла-бла… получилось вот такое решение (SQL запрос/ORM, объекты) с такими затратами по памяти/времени и вот такими перспективами под будущие нужды. А теперь мы перенесём это в NoSQL — получилась вот такая выборка, вот на столько стало МЕНЬШЕ(?) кода/времени/памяти и вот так увеличилась гибкость по расширению системы». Если бы я это прочёл, я бы выкинул нафик все свои базы, побрил голову (так принято) и пошёл к вам в ученики. :) Но ничего этого я не увидел, поэтому и написал своё мнение: ваш выбор сугубо индивидуальный и не показывает НИКАКИХ преимуществ, почему нужно делать решение именно на NoSQL.
«Так учитываются «требования» или нет??»
Конечно учитываются. Еще раз — выбор пал на монгу из за того, что в свете изложенных выше требований с ней легче работать.
Не быстрее, не правильнее, а легче.
«вот на столько стало МЕНЬШЕ(?) кода/времени/памяти и вот так увеличилась гибкость по расширению системы»
По большому счету не важно, медленнее работает монга или быстрее чем та же MySQL, в конце концов узкие участки всегда можно будет переложить на MySQL. Важнее именно удобство разработки, об этом и статья.
«ваш выбор сугубо индивидуальный»
Именно так.
Конечно учитываются. Еще раз — выбор пал на монгу из за того, что в свете изложенных выше требований с ней легче работать.
Не быстрее, не правильнее, а легче.
«вот на столько стало МЕНЬШЕ(?) кода/времени/памяти и вот так увеличилась гибкость по расширению системы»
По большому счету не важно, медленнее работает монга или быстрее чем та же MySQL, в конце концов узкие участки всегда можно будет переложить на MySQL. Важнее именно удобство разработки, об этом и статья.
«ваш выбор сугубо индивидуальный»
Именно так.
> «ваш выбор сугубо индивидуальный» — Именно так.
В принципе, этого ответа достаточно, но технически вы не указали никаких преимуществ в пользу NoSQL. Вот требования:
Требование 1. Мультиязычные поля
Ни бог весть какое требование, локализация — уже давно решённый вопрос. NoSQL никаких преимуществ тут не даёт.
Требование 2. Связи
Опять же, даже вы сами указали несколько решений, все они приемлемы в зависимости от требований задачи. И к слову, NoSQL тут вообще ничем не помогает: docs.mongodb.org слэш manual/reference/database-references/ — такое же «костыльное» решение как у обычного SQL.
Требование 3. Объекты с разным набором полей в одной таблице
Ради бога! Не путайте «нам нужно вывести список на страничку» с «нам нужно всё хранить в одной таблице» — это РАЗНЫЕ вещи. Никто не мешает получить десять списков РАЗНЫХ объектов и вывести хронологически, LINQ вам в помощь.
Требование 4. Сложные объекты
Ну сложные, и чо? Та сумбурщина, которую вы описали — не повод прыгать в какие-то маргинальные решения. Тот же JSON в PostgreSQL вполне «поискуем». Я уже в курсе, что PostgreSQL не рассматривался вообще — серьёзное упущение, но всё равно никаким боком не дающее NoSQL преимуществ — весь вопрос лишь в понимании требований.
Итого, вы просто взяли решение «потому что вам нравится» и описали как вы им решили задачу (ещё вопрос, «насколько эффективно») — я бы такую «рекомендацию» не стал бы даже читать, не то что писать. Это натуральный упадок технической подкованности — неспособность «инженерно» подходить к решению задач, но при этом «как бы технически» расписывать целую статью в пользу личного выбора.
«Я выбрал MongoDB, потому что это модно и там есть полноценный яваскрипт в консоли» — вот и весь грустный смысл статьи. :(
В принципе, этого ответа достаточно, но технически вы не указали никаких преимуществ в пользу NoSQL. Вот требования:
Требование 1. Мультиязычные поля
Ни бог весть какое требование, локализация — уже давно решённый вопрос. NoSQL никаких преимуществ тут не даёт.
Требование 2. Связи
Опять же, даже вы сами указали несколько решений, все они приемлемы в зависимости от требований задачи. И к слову, NoSQL тут вообще ничем не помогает: docs.mongodb.org слэш manual/reference/database-references/ — такое же «костыльное» решение как у обычного SQL.
Требование 3. Объекты с разным набором полей в одной таблице
Ради бога! Не путайте «нам нужно вывести список на страничку» с «нам нужно всё хранить в одной таблице» — это РАЗНЫЕ вещи. Никто не мешает получить десять списков РАЗНЫХ объектов и вывести хронологически, LINQ вам в помощь.
Требование 4. Сложные объекты
Ну сложные, и чо? Та сумбурщина, которую вы описали — не повод прыгать в какие-то маргинальные решения. Тот же JSON в PostgreSQL вполне «поискуем». Я уже в курсе, что PostgreSQL не рассматривался вообще — серьёзное упущение, но всё равно никаким боком не дающее NoSQL преимуществ — весь вопрос лишь в понимании требований.
Итого, вы просто взяли решение «потому что вам нравится» и описали как вы им решили задачу (ещё вопрос, «насколько эффективно») — я бы такую «рекомендацию» не стал бы даже читать, не то что писать. Это натуральный упадок технической подкованности — неспособность «инженерно» подходить к решению задач, но при этом «как бы технически» расписывать целую статью в пользу личного выбора.
«Я выбрал MongoDB, потому что это модно и там есть полноценный яваскрипт в консоли» — вот и весь грустный смысл статьи. :(
Локализация.
«NoSQL никаких преимуществ тут не даёт.»
С NoSQL это делать гораздо удобнее.
Связи.
«несколько решений, все они приемлемы в зависимости от требований задачи»
Проще связь хранить в самом объекте — в MongoDB это делать удобно.
Объекты с разным набором полей в одной таблице
«Ради бога! Не путайте «нам нужно вывести список на страничку» с «нам нужно всё хранить в одной таблице» — это РАЗНЫЕ вещи»
Я ничего не путаю. Я НЕ хочу их хранить в разных таблицах. Мне удобнее хранить их в одной. И проще это делать в MongoDB.
Сложные объекты
«Тот же JSON в PostgreSQL вполне «поискуем»»
Мне хватает поискуемости в MongoDB.
Итого, вы предлагаете набор разных частных решений, для того, что можно решить (и уже решено) нормально одним инструментом.
«NoSQL никаких преимуществ тут не даёт.»
С NoSQL это делать гораздо удобнее.
Связи.
«несколько решений, все они приемлемы в зависимости от требований задачи»
Проще связь хранить в самом объекте — в MongoDB это делать удобно.
Объекты с разным набором полей в одной таблице
«Ради бога! Не путайте «нам нужно вывести список на страничку» с «нам нужно всё хранить в одной таблице» — это РАЗНЫЕ вещи»
Я ничего не путаю. Я НЕ хочу их хранить в разных таблицах. Мне удобнее хранить их в одной. И проще это делать в MongoDB.
Сложные объекты
«Тот же JSON в PostgreSQL вполне «поискуем»»
Мне хватает поискуемости в MongoDB.
Итого, вы предлагаете набор разных частных решений, для того, что можно решить (и уже решено) нормально одним инструментом.
«Гораздо удобнее» это слишком субъективный фактор, чтобы его приводить как доказательство.
" его приводить как доказательство"
Так я вроде ничего и не доказываю.
Так я вроде ничего и не доказываю.
Вы доказываете «обоснованность выбора». Увы, вы сделали эмоциональный выбор, который пытаетесь теперь рационализировать, а люди вам не верят.
Я кстати даже прекрасно понимаю почему вы выбрали Mongo — вы не умеете работать с SQL. Генерацию запросов и поддержку схемы не осилили. Я не знаю как это решается в Python, но в C# с Linq подобных проблем и близко нет.
Я кстати даже прекрасно понимаю почему вы выбрали Mongo — вы не умеете работать с SQL. Генерацию запросов и поддержку схемы не осилили. Я не знаю как это решается в Python, но в C# с Linq подобных проблем и близко нет.
«Я кстати даже прекрасно понимаю почему вы выбрали Mongo — вы не умеете работать с SQL»
Я с SQL работаю больше 11 лет. И прямые запросы и orm и как угодно.
Я с SQL работаю больше 11 лет. И прямые запросы и orm и как угодно.
Суд по посту это не так. Вы даже при проектировании не учли ни уникальные индексы, ни композитные ключи, ни возможность джоинов по неключивым полям.
Наверно потому что это пример того, какие поля нужны были, а не реальные таблицы?
Тогда какой смысл в этом примере? Вы же сделали вид, что это схема БД, а теперь оказывается что это не схема БД, а вольные фантазии на эту тему?
И вообще почти ни слова нет о запросах. Без этого нет смысла движки обсуждать вообще.
И вообще почти ни слова нет о запросах. Без этого нет смысла движки обсуждать вообще.
«Тогда какой смысл в этом примере?»
Очевидно, что бы пояснить, какие могут быть варианты решения одной и той же задачи.
Очевидно, что бы пояснить, какие могут быть варианты решения одной и той же задачи.
Вариантов решения в итоге нет. Ваши умозаключения выглядят так:
1) (была какая-то задача, о которой вы не сказали)
2) вы придумали набор полей и связей (на самом деле не явно насколько этот набор адекватен задаче)
3) (вы сделали нечто на MySQL, об этом вы тоже не говорите почти ничего)
4) потом сделали на MongoDB — получилось быстрее.
То есть два ключевых момента — что сделали и почему сделали у вас не описано. А все остальное это вкусовщина.
1) (была какая-то задача, о которой вы не сказали)
2) вы придумали набор полей и связей (на самом деле не явно насколько этот набор адекватен задаче)
3) (вы сделали нечто на MySQL, об этом вы тоже не говорите почти ничего)
4) потом сделали на MongoDB — получилось быстрее.
То есть два ключевых момента — что сделали и почему сделали у вас не описано. А все остальное это вкусовщина.
Есть требования, варианты их решения и описан выбор который был сделан по каждому требованию для MySQL.
Потом была миграция с MySQL на «нечто» и пример того, как стали хранится данные в этом «нечто» и насколько это стало удобнее.
Потом описание знакомства с MongoDB, организация хранения данных в котором было очень похожа на то решение, к которому мы сами пришли эволюционно.
По крайней мере в статье я хотел описать именно это. Если это не получилось, ну чтож — значит мне нужно треннироваться яснее выражать свои мысли.
Потом была миграция с MySQL на «нечто» и пример того, как стали хранится данные в этом «нечто» и насколько это стало удобнее.
Потом описание знакомства с MongoDB, организация хранения данных в котором было очень похожа на то решение, к которому мы сами пришли эволюционно.
По крайней мере в статье я хотел описать именно это. Если это не получилось, ну чтож — значит мне нужно треннироваться яснее выражать свои мысли.
Еще раз:
1) «Требования» являются просто фантазией, если ты не озвучил решаемую проблему в терминах потребителя.
2) Из п1 следует что удобство в этом случае очень субъективно и скорее связано с твоим опытом, чем с реальными преимуществами.
3) Ты же сам сослался на мой перевод про MongoDB, в нем более половины объема уделено описанию решаемых задач.
1) «Требования» являются просто фантазией, если ты не озвучил решаемую проблему в терминах потребителя.
2) Из п1 следует что удобство в этом случае очень субъективно и скорее связано с твоим опытом, чем с реальными преимуществами.
3) Ты же сам сослался на мой перевод про MongoDB, в нем более половины объема уделено описанию решаемых задач.
Мы говорим локализация и думаем про gettext, мы говорим пр геттекст и думаем про локализацию. И не важно какое у вас хранилище воообще.
Теперь про хранилище. На что только люди не идут чтобы только не использовать PostgreSQL :)
Для уникальности записей на одном языке если уж на то пошло есть такая вещь как уникальность и составные индексы.
Хранить всё в одной табличке вам не нужно. Уверен.
Для связей есть hstore, для JSON есть JSON.
Так и не понял зачем вам нужен был NoSQL (При том условии что он не нужен вообще. )
Вообще предлагаю запретить такие статьи писать на хабр. Или минусовать нещадно. Но чтобы никто не мог аппелировать к таким статьям как «хорошему примеру».
Теперь про хранилище. На что только люди не идут чтобы только не использовать PostgreSQL :)
Для уникальности записей на одном языке если уж на то пошло есть такая вещь как уникальность и составные индексы.
Хранить всё в одной табличке вам не нужно. Уверен.
Для связей есть hstore, для JSON есть JSON.
Так и не понял зачем вам нужен был NoSQL (При том условии что он не нужен вообще. )
Вообще предлагаю запретить такие статьи писать на хабр. Или минусовать нещадно. Но чтобы никто не мог аппелировать к таким статьям как «хорошему примеру».
«Мы говорим локализация и думаем про gettext, мы говорим пр геттекст и думаем про локализацию. И не важно какое у вас хранилище воообще. „
Вы не правы. У нас почти сразу разделилась контентная часть и дизайн. Для дизайна удобно использовать gettext. Для контентной части нет.
Вы не правы. У нас почти сразу разделилась контентная часть и дизайн. Для дизайна удобно использовать gettext. Для контентной части нет.
И чем неудобно?
Есть у нас таблица с типами названий компании — выше на скриншоте. Там есть мультиязычное поле name, которое мы выгружаем в pot файл и отдаем на перевод, сюда бы gettext подошел.
А вот с играми так делать неудобно. Во первых очень часто у игры есть только название на родном языке, которое максимум переведено на английский и его просто не имеет смысла еще куда то переводить. Во вторых у игры может быть описание и на разных языках оно может быть разным, ну то есть на русском один набор предложений, на английском другой. Зачастую у игр может просто не быть английского варианта перевода или, например, английское название имеет один смысл, а русское другой (так уж переводчики перевели), или есть две игры у которых на английском совпадают имена, а на русском нет. Плюс ко всему например русских описаний может быть два, а английское одно.
Такое проще решается без gettext.
А вот с играми так делать неудобно. Во первых очень часто у игры есть только название на родном языке, которое максимум переведено на английский и его просто не имеет смысла еще куда то переводить. Во вторых у игры может быть описание и на разных языках оно может быть разным, ну то есть на русском один набор предложений, на английском другой. Зачастую у игр может просто не быть английского варианта перевода или, например, английское название имеет один смысл, а русское другой (так уж переводчики перевели), или есть две игры у которых на английском совпадают имена, а на русском нет. Плюс ко всему например русских описаний может быть два, а английское одно.
Такое проще решается без gettext.
Проектирование любой СУБД надо начинать с того какие у вас запросы. Вы описали все что можно, кроме запросов. Я могу на тех же входных данных, что вы привели, обосновать использование абсолютно любого хранилища.
Sign up to leave a comment.
Почему мы выбрали MongoDB