• Как уже сейчас пощупать транзакции в MongoDB

    Летом 2018 года (т.е. прямо сейчас, на момент написания данной статьи) случилось невероятное — в MongoDB завезли честные ACID транзакции. С выходом четвёртой версии этой документ-ориентированной СУБД, её можно использовать для чуть более серьёзных приложений.


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


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

    Погнали!
  • Shopkeeper 4.0 — Интернет-магазин на Symfony + Angular + MongoDB


      История


      Немного предыстории. Первая версия Shopkeeper вышла в 2009 году. Тогда это был модуль для CMS MODX, а точнее для первой его ветки, которая сейчас называется Evolution. В то время у MODX был всего один подобный модуль, но его качество меня не устраивало, поэтому я решил написать свой. Плюс нужен был какой-то проект для наращивания опыта в программировании на PHP. Т.к. конкуренции почти не было, мой компонент стал самым популярным для той версии MODX.
      Читать дальше →
    • JOIN в NoSQL базах данных

        В этом сообщении будут рассмотрены способы соединения коллекций в NoSQL базах данных mongodb, arangodb, orientdb и rethinkdb (помимо того, что это NoSQL базы данных, их объединяет еще и наличие бесплатной версии с достаточно лояльной лицензией). В реляционных базах данных аналогичная функциональность реализуется при помощи SQL JOIN. Несмотря на то, что CRUD — операции в NoSQL базах данных очень похожи и различаются только в деталях, например, в одной базе данных для создания объекта используется функция create({… }), в другой — insert({… }), а в третьей — save({… }), — реализация выборки из двух и более коллекций в каждой из баз данных реализована совершенно по-разному. Поэтому будет интересно выполнить на всех базах данных одинаковую выборку. Для всех баз будет рассмотрено получение выборки (связь типа многие-ко многим) для двух таблиц.
        Читать дальше →
        • +13
        • 5,5k
        • 4
      • graphql — оптимизация запросов к базе данных

        • Tutorial
        При работе с базами данных существует проблема которую принято называть «SELECT N + 1» — это когда приложение вместо одного запроса к базе данных, который выбирает все необходимые данные из нескольких связанных таблиц, коллекций, — делает дополнительный подзапрос для каждой строки результата первого запроса, чтобы получить связанные данные. Например, сначала мы получаем список студентов университета, в котором его специальность обозначена идентификатором, а потом для каждого из студентов делаем дополнительный подзапрос в таблицу или коллекцию специальностей, чтобы по идентификатору специальности получить наименование специальности. Поскольку каждый из подзапросов может потребовать еще один подзапрос, и еще один подзапрос — колчество запросов к базе данных начинает расти в геометрической прогрессии.

        При работе с graphql очень просто породить проблему «SELECT N + 1», если в resolver-функции сделать подзапрос к связанной таблице. Первое что приходит в голову — сделать запрос сразу с учетом всех связанных данных, но это, согласитесь, нерационально, если связанные данные не запрашиваются клиентом.

        Один из вариантов решения проблемы «SELECT N + 1» для graphql будет рассмотрен в этом сообщении.
        Читать дальше →
      • Maraquia — ORM для MongoDB

          После прочтения заголовка у многих наверняка возникает вопрос — зачем ещё один велосипед при наличии уже обкатанных Mongoose, Mongorito, TypeORM и т. д.? Для ответа нужно разобраться в чём отличие ORM от ODM. Смотрим википедию:


          ORM (англ. Object-Relational Mapping, рус. объектно-реляционное отображение, или преобразование) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных».

          То есть ORM — это именно про реляционное представление данных. Напомню, в реляционных БД нет возможности просто взять и встроить документ в поле другого документа (в этой статье записи таблиц тоже называются документами, хоть это и некорректно), можно конечно хранить в поле JSON в виде строки, но индекс по данным в нём сделать не выйдет. Вместо этого используются "ссылки" — в поле, где должен быть вложенный документ, вместо него записывается его идентификатор, а сам документ с этим идентификатором сохраняется в соседней таблице. ORM умеет работать с такими ссылками — записи по ним автоматически сразу или лениво забираются из БД, а при сохранении не нужно сперва сохранять дочерний документ, брать назначенный ему идентификатор, записывать его в поле родительского документа и только после этого сохранять родительский документ. Нужно просто попросить ORM сохранить родительский документ и всё что с ним связано, а он (object-relational mapper) уже сам разберётся как это правильно сделать. ODM же наоборот, не умеет работать с такими ссылками, зато знает про встроенные документы.

          Читать дальше →
        • Нечеткий поиск (fuzzy search) в реляционных базах данных

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

            Решения с использованием elasticsearch имеют один существенный недостаток — очень большая вероятность рассогласования основной базы данных, например PostgreSQL, MySQL, mongodb и elasticsearch, в которой хранятся индексы для поиска.
            Читать дальше →
            • +10
            • 5,4k
            • 6
          • Ой, у вас баннер убежал!

            Ну. И что?
            Реклама
          • Может поможет

              Есть предложение. В связи с блокировками, давайте все массово просто попросим. Я понимаю, смешно. Но что то делать нужно. На https://rkn.gov.ru/ в самом низу есть «Сообщить об ошибке (Ctrl + Enter)». Давайте писать. Просто писать.


              Я писал о docs.mongodb.com.


              Присоединяйтесь. Вдруг что-то изменится?

            • Онлайн имплементация localStorage

              Хочу поделиться тем, как приватный режим Safari привел к разработке простого ключ-значение хранилища на Node.js с резервным копированием, доступом к данным с определенных доменов и защитой паролем от записи и очистки хранилища.



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

              Задача была решена и работала следующим образом:

              1. неавторизованный пользователь кликает на магазин (ссылка «_blank»);
              2. в новом окне отображаются тестовые товары, а в iframe мы перенаправляем пользователя в профиль тестового пользователя и ждем появления данных покупки в localStorage;
              3. после совершения покупки, данные о ней сохраняем в localStorage (сумма, количество, магазин, время покупки и количество бонусов)
              4. в iframe при появлении данных тестовой покупки в localStorage, мы отображаем информацию в блоке «история покупок»;

              Все работало в большинстве браузеров, и даже в IE11, но только не в Safari, чья политика безопастности (более известный как porno-mode) не разрешала получить доступ к данным localStorage одного и того же домена внутри iframe и снаружи (в новом окне).

              Нужно где-то хранить промежуточные данные, привлечь к этой задачи бэкенд разработчиков для создания какого-либо API для хранения данных разрешения не получил, оставалось только найти какое-нибудь онлайн хранилище, с возможностью создание для каждого пользователя своего токена.
              Читать дальше →
            • Готовый шаблон сайта с регистрацией, юзерами и админами на Flask с базами SQL или MongoDB

                flask

                Бывает, приходится делать сайты на flask, у которых есть пользователи и админы. Чисто для себя решил как-то это стандартизировать и, главное, не терять время, когда такая задача появляется. Цель — в несколько команд получить рабочий сайт у которого есть:

                • Регистрация
                • Email подтверждение
                • Авторизация
                • Выход (logout)
                • Администраторы и роли администраторов
                • Административная, пользовательская и публичная часть сайта
                • Возможность юзера менять пароль
                • Восстановление пароля
                • Локализация для иностранных языков
                Читать дальше →
              • Рассуждение на тему, какую базу данных выбирать

                  Эта статья для вас, если вы:


                  • выбираете базу данных для нового проекта и изучаете информацию про разные варианты;
                  • считаете, что текущая база данных не устраивает вас по каким то параметрам и вы хотите ее сменить, но у вас нет хорошего специалиста;
                  • просто хотите почитать в одной статье про несколько баз данных и когда можно их использовать.

                  Моя статья не для вас, если вы:


                  • хорошо умеете готовить свою любимую БД, оптимизировать индексы, настраивать и всякое такое;
                  • имеете в штате хорошего специалист, который сможет аргументировано выбрать нужный вашему проекту вариант. специалист должен быть действительно хорошим, а не «экспертом на диване»;
                  • обслуживаете проект с так называемым «big data», то есть у вас огромные базы, десятки или сотни серверов в кластере и всякое такое — ну у вас как бы должен быть в штате один или несколько специалистов.

                  О чем пойдет речь в статье?


                  Я разберу в своей статьи некоторые типичные и не очень варианты выбора баз данных, а если быть более точным — подходы к выбору. Когда следует остановится на том, что используют большинство, а когда можно и задуматься над новым и неизведанным. Я опишу СУБД MySQL, PostgreSQL, MongoDB, Redis, CouchDB/PouchDB и упомяну о Aerospike с Tarantool, парочку других — но в некоторых моментах конкретный выбор не настолько принципиален. Надо понимать, что лучше изначально правильно спроектировать структуру данных, чем выбрать СУБД, а потом уже пытаться придумывать, что в ней собственно хранить.
                  Итак, начнем.
                  Читать дальше →
                Самое читаемое