Комментарии

Комментарии можно хранить в отдельной коллекции. Удобней будет делать запросы, сортировки, поиск.

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

Так это как раз плохой пример. У монги же лок на запись на уровне документа. Причём как я понял из доков, лок на уровне документа доступен на движке WiredTiger, по-умолчанию лок на базу до сих пор (или я не там читал?)

Что если сразу куча народу захочет написать или подредактировать комменты? А если кто-то начнёт удалять свой коммент, а ему в этот момент начнут отвечать?

Документоориентированные СУБД такие, как MongoDB, прекрасно справляются с хранением JSON-данных, сгруппированных в «коллекции». В таком формате можно хранить любые JSON-документы и удобно категоризировать и по коллекциям. Содержащийся в MongoDB JSON-документ называется двоичным JSON или BSON и, как любой другой документ этого формата, является неструктурированным. Поэтому, в отличии от традиционных СУБД, в коллекциях можно сохранять любые виды данных, и эта гибкость сочетается с горизонтальной масштабируемостью базы данных. Эта возможность нравится многим разработчикам, однако «не все так однозначно».

Если MongoDB такая классная, почему ее не используют все и всегда?

Выбор СУБД зависит в том числе и от того, что за приложение планируется создать. То есть базу данных выбирают не разработчики, а сам продукт, убежден Дандала. Он приводит пример, подтверждающий этот тезис.

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

Однако, необходимо отметить, что у MongoDB нет связей между документами и “коллекциями” (частично это компенсируется Database Reference — ссылками в СУБД, но это не полностью решает проблему). В итоге, возникает ситуация, при которой имеется некий набор данных, который никак не связан с другой информацией в базе, и не существует никакого способа объединить данные из различных документов. В SQL-системах это было бы элементарной задачей.

Здесь возникает другой вопрос — если в MongoDB нет связей и возможностей по объединению двух таблиц, то зачем ее тогда вообще использовать? Ответ — потому что эта СУБД отлично масштабируется, и по сравнению с традиционными SQL-системами, гораздо быстрее осуществляет чтение и запись.MongoDB прекрасно подходит для приложений, в которых практически не используются данные с зависимостями и необходима масштабируемость базы данных.

Многие разработчики применяют MongoDB и для хранения связанных данных, реализуя объединения вручную в коде — этого достаточно в сценариях «одноуровневого» объединения или малого количества связей. То есть данный метод далеко не универсален.

Так какую СУБД выбрать?

Существует огромное количество различных СУБД, и каждая из них соответствует определённому набору требований, которые разработчики предъявляют к своему приложению:

— Документоориентированные СУБД (к примеру, MongoDB): Как уже сказано выше, документоориентированные СУБД используются для хранения JSON-документов в “коллекциях” и осуществления запросов по нужным полям. Можно использовать эту базу данных для создания приложений, в которых не будет содержаться слишком большого количества связей. Хорошим примером такого приложения является движок для блог-платформы или хранения каталога продуктов.
— Графовые СУБД (например Neo4j): Графовая СУБД используется для хранения между субъектами, где узлы являются субъектами, а грани — связями. Например, если разработчики создают социальную сеть, и один пользователь подписывается на другого, то пользователи являются узлами, а их “подписка” — связью. Такие СУБД прекрасно справляются с образованием связей, даже если глубина таких связей более ста уровней. Этот инструмент столь эффективен, что может даже позволяет выявлять мошенничество в сфере электронной коммерции.
— Кэш (например Redis): Такие СУБД используются, когда требуется крайне быстрый доступ к данным. Если создается приложение для интернет-торговли, в котором есть подгружаемые на каждой страницы категории, то вместо обращения к базе данных при каждом чтении, что крайне затратно, можно хранить данные в кэше. Он позволяет быстро осуществлять операции чтения/записи. Дандала советует применять СУБД, использующие кэш, в качестве оболочки для обработки часто запрашиваемых данных, избавляющей от необходимости совершения частых запросов к самой базе.
— Поисковые СУБД (например ElasticSearch): В случае необходимости осуществления полнотекстового поиска по базе данных (например поиск продукции в ecommerce-приложении), то хорошей идее будет использование поисковой СУБД вроде ElasticSearch. Эта система способна искать по огромному массиву данных и обладает обширной функциональностью — например, СУБД умеет осуществлять поиск по именованным категориям.
— Строковые СУБД (например Cassandra): СУБД Cassandra используется для хранения последовательных данных, логов, или огромного объема информации, который может генерироваться автоматически — к примеру, каким-нибудь датчиками. Если разработчики собираются использовать СУБД для записи больших массивов данных и при этом планируется, что будет намного меньше обращений для чтения и данные не будут иметь связи и объединения, тогда Cassandra будет хорошим выбором, уверен Дандала.

Существуют и ситуации, в которых может понадобиться использование сразу нескольких различных СУБД.

Например, если в приложении есть функция поиска, то его можно реализовать с помощью ElasticSearch, а уже для хранения данных без связей лучше подойдет MongoDB. Если речь иет о проекте в сфере «интернета вещей», где огромное количество всевозможных устройств и датчиков генерируют гигантские объёмы данных, вполне разумно будет использовать Cassandra.

Принцип, при котором используются несколько СУБД для работы в одном приложении, называется “Polyglot Persistence”. В этой статье можно почитать о плюсах и минусах такого подхода.

Наш опыт

Наша биллинговая система использует для учета первичных данных и хранения финансовой информации реляционную СУБД. Она идеально подходит для этих целей. Но некоторые модули Гидры, например, RADIUS-сервер, работают под высокой нагрузкой и могут получать тысячи запросов в секунду с жесткими ограничениями на время обработки запроса. Кроме того, в БД нашего автономного RADIUS-сервера данные хранятся в виде набора AVP (attribute/value pair). В таком сценарии реляционная СУБД уже не выглядит лучшим решением, и тут на помощь приходит MongoDB с ее хранилищем документов произвольной структуры, быстрой выдачей ответа и горизонтальной масштабируемостью.

При эксплуатации более чем на 100 инсталляциях Гидры на протяжении последних 5 лет серьезных проблем с Mongo мы не обнаружили. Но пара нюансов все же есть. Во-первых, после внезапного отключения сервера БД хоть и восстанавливается благодаря журналу, но происходит это медленно. К счастью, необходимость в этом возникает нечасто. Во-вторых, даже при небольшом размере БД редко используемые данные сбрасываются на диск и когда запрос к ним все же приходит, их извлечение занимает много времени. В результате нарушаются ограничения на время выполнения запроса.

Все это относится к движку MMAPv1, который применяется в Mongo по умолчанию. С другими (WiredTiger и InMemory) мы пока не экспериментировали — проблемы не настолько серьезны.

Жесть конечно, но можно только похвалить архитекторов, которые внедрили такое использование TDD в свое время.
Такой продукт сейчас — заложник себя самого. Переписать с сохранением всех фич такое невозвожно за разумное время. Приходится жить с чем есть.

На этой неделе пользователи Hacker News решили обсудить вопрос «Каков максимальный объем плохого — но при этом работающего — кода вам доводилось видеть?» (позже к ним присоединились и пользователи Reddit). В комментариях было рассказано немало «веселых» историй про то, с чем мы все время от времени сталкиваемся; но больше всего внимания привлек рассказ про код «передовой СУБД, которую используют большинство компаний, входящих в список Fortune 100».

Победителем в номинации «лавкрафтовские ужасы» заслуженно стал рассказ бывшего разработчика Oracle, который работал над Oracle Database в период разработки версии 12.2. Объем кодовой базы СУБД на тот момент составлял 25 миллионов строк на языке C — и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов.

За прошедшие годы над кодом успело потрудиться несколько поколений программистов, которых регулярно преследовали жесткие дедлайны — и благодаря этому код смог превратиться в настоящий кошмар. Сегодня он состоит из сложных «кусков» кода, отвечающих за логику, управление памятью, переключение контекстов и многое другое; они связаны друг с другом при помощи тысяч различных флагов. Весь код связан между собой загадочным макросом, который невозможно расшифровать, не прибегая к помощи тетради, в которую приходится записывать, чем занимаются релевантные части макроса. В итоге, у разработчика может уйти день или два только на то, чтобы разобраться, чем же в действительности занимается макрос.

Для того, чтобы предсказать поведение кода в том или ином случае, приходится разбираться и запоминать, какие значения и последствия могут иметь 20 (а то и сотня) флагов. Ситуацию ухудшает тот факт, что различные разработчики использовали свои собственные типы, которые по своей сути представляли собой одно и то же (например, int32) — и едва ли кто-то рискнет тронуть подобное легаси (можно точно сказать, что это имело место быть в кодовой базе Oracle 8i).

Возникает вопрос: каким же образом при всем этом Oracle Database до сих пор удается держаться на ногах? Секрет — в миллионах тестов. Их полное выполнение может занимать от 20 до 30 часов (при этом выполняются они распределенно на тестовом кластере из 100-200 серверов).

В команде, которая работала над продуктом в конце 90-ых и придерживалась идей TDD (test-driven development), бытовало следующее мнение: «автоматизированные тесты означают то, что вы не обязаны писать код, который можно будет понять – вместо этого за вас должны думать тесты». В дальнейшем разработчики были вынуждены придерживаться заложенных ими принципами, и теперь мы на практике наблюдаем, чем обернулась эта идея в долгосрочной перспективе — со всеми ее плюсами и минусами.

Сегодня процесс исправления нового бага в Oracle Database занимает от нескольких недель до нескольких месяцев. Сначала разработчику приходится тратить несколько дней только на то, чтобы разобраться с нужными ему флагами (загадочное взаимодействие которых и вызывает баг), после чего ему зачастую приходится добавлять свой собственный флаг, который будет отвечать за обработку конкретного сценария, вызывавшего баг.

Затем он отправляет код на тестирование, и на следующий день спокойно переключается на другую задачу, ожидая, пока тестовый кластер соберет новую сборку Oracle DB и прогонит на ней все тесты. Если разработчику повезло, «покраснеет» примерно 100 тестов; если нет (и этот вариант случается чаще) — около 1000, и ему придется проверять, какое из его предположений о работе существующего кода оказалось неверным; вполне возможно, что он обнаружит, что ему требуется изучить еще десяток различных флагов, которые неочевидным образом принимали участие в работе кода, который он изменил.

Этот процесс ему придется повторять в течении пары недель, прежде чем ему наконец не улыбнется удача и все тесты наконец-то пройдут. После чего он сам должен будет написать несколько десятков тестов — для того, чтобы убедиться, что разработчик, который потревожит его код в будущем, не поломает его «фикс». Затем доработки отправятся на ревью, которое может занимать от нескольких недель до пары месяцев, после чего баг наконец-то будет смержен в главную рабочую ветку.

В силу того, что на сборку СУБД и выполнение тестов уходит не менее суток, ожидается, что каждый разработчик работает одновременно над 2-3 багами и переключается между ними, пока ждет результатов тестирования.

Если вы подумали, что жизнь разработчиков, добавляющих в СУБД новый функционал, легче – то это вы зря. Добавление даже небольшой новой фичи вроде нового режима аутентификации может занимать от 6 месяцев до года, в особо запущенных случаях — до двух лет.

В описанном случае, TDD позволяет не рассыпаться «спагетти»-коду, в котором уже крайне сложно что-то понять, и иметь на выходе рабочий продукт. При этом, издержки продолжают расти, и качество нового кода часто оставляет желать лучшего. Над СУБД работает не только команда разработчиков из США, но и команда из Индии, поэтому некоторые разработчики Oracle по сложившейся традиции сваливают вину за качество кода на них. Другие с ними не согласны, и основываясь на changelog заявляют, что качество кода не зависит от географии команды, и плохой код периодически «прилетает» от обеих команд. По-настоящему серьезная проблема для продукта — это разработчики, которые воспринимают проект как «вход в индустрию», и работают над СУБД не дольше 1-2 года; за это время существенно разобраться в тонкостях работы проекта невозможно.

По свидетельствам другого разработчика, который занимался портированием кодовой базы Oracle 8i на одну из версий Unix в конце 90-ых, код уже на тот момент представлял собой клубок «спагетти», который понять целиком было решительно невозможно. Еще один разработчик, который работал с кодом СУБД в конце 80-ых, утверждает, что тогда кодовая база представляла собой огромную кучу из исходников на C и набора makefile для сборки — многие из которых были устроены гораздо сложнее, чем код самого ядра. Конечно, стоит быть реалистами — едва ли ситуация обстоит лучше в аналогичных продуктах-лидерах индустрии, разработка которых велась в течение нескольких десятков лет.

У множественной первичной репликации, которая позволяет нескольким репликам принимать обновления независимо, я бы выделил слудеющие преимущества:
— Увеличенная пропускная способность при записи. Несколько реплик могут обрабатывать запросы на запись одновременно, повышая общую пропускную способность системы.
— Меньшая задержка записи. Записи могут обрабатываться локально в каждой реплике, что сокращает задержку по сравнению с централизованными моделями первичного резервного копирования.
— Отказоустойчивость. Даже если одна реплика выходит из строя, другие реплики могут продолжать принимать операции записи и выполнять операции чтения.

Недостатки: одновременное обновление нескольких основных файлов может привести к конфликтам, которые необходимо разрешить.

Распределённая репликация распределяет данные или услуги по нескольким узлам менее структурированным образом. Реплики могут быть расположены географически или логически распределены по сети.

Преимущества:
— Масштабируемость. Распределённая репликация поддерживает горизонтальную масштабируемость, позволяя динамически добавлять или удалять реплики по мере изменения требований рабочей нагрузки.
— Отказоустойчивость. Резервирование между распределёнными репликами повышает отказоустойчивость и надёжность системы.

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

Такие стратегии, как первичное резервное копирование, мультиосновная или распределенная репликация, различаются по масштабируемости, влияя на производительность, балансировку нагрузки и согласованность при динамике узла.

А тогда еще вопрос — как различные стратегии репликации влияют на масштабируемость системы, особенно с точки зрения динамического добавления или удаления узлов?

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

Спасибо за подробную статью, интересно а каковы основные проблемы при реализации репликации с несколькими основными элементами и как разрешение конфликтов влияет на производительность системы и целостность данных?

Тут ничего сложного в файле
templates\default\controllers\news\item_view.tpl.php

Добовляем

<?php
function insertAdBlock($content) {
    // Разбиваем контент на массив слов
    $words = explode(' ', $content);
    // Находим середину массива
    $middleIndex = floor(count($words) / 2);
 
    // Создаем две части контента
    $firstHalf = array_slice($words, 0, $middleIndex);
    $secondHalf = array_slice($words, $middleIndex);
 
    // HTML код рекламного блока
    $adBlock = '<div class="mt-4 mb-2"><div class="banner-full"><a href="https://dstglobal.ru/products" title="Баннер"><img src="/templates/default/images/101.webp"></a></div></div>';
 
    // Вставляем рекламный блок между двумя частями контента
    $newContent = implode(' ', $firstHalf) . ' ' . $adBlock . ' ' . implode(' ', $secondHalf);
 
    return $newContent;
}
 
// Пример использования
$contentWithAd = insertAdBlock($item['content']);
?>

Далее меняем

<div class="club-item-content">
        <?php echo $contentWithAd; ?>
    </div>

B2C — business to customer, «бизнес — потребителю». Площадки, где ИП или компании предлагают товары или услуги физическим лицам. Очевидный пример — популярные маркетплейсы Wildberries, Ozon, Яндекс Маркет.На этих площадках могут также покупать компании и предприниматели: например, на Яндекс Маркете есть отдельный раздел покупок для бизнеса. Но большая доля покупателей на B2C-площадках — обычные люди. Для такого типа подходит система DST Маркетплейс

B2B — business to business, «бизнес — бизнесу». Площадки, где одни ИП и компании продают товары другим ИП и компаниям. Работают B2B-маркетплейсы так же, как Wildberries и Ozon: площадка привлекает поставщиков и выставляет их товар на витрине. Но сделать заказ сможет только предприниматель или организация. По такой модели работают, например, китайский Alibaba, площадки «Рывок» и «Пульс цен». Для такого типа подходит система DST Мультивендор

C2C — customer to customer, «потребитель — потребителю». Площадка, где физические лица могут покупать друг у друга товары или обмениваться ими. Пользователи сами управляют ценами и определяют время и способ доставки. Самый известный пример C2C-маркетплейса — Авито. Но сейчас предлагать товары и услуги на этой площадке может и бизнес. Для такого типа подходит система DST Маркетплейс

B2C — business to customer, «бизнес — потребителю». Площадки, где ИП или компании предлагают товары или услуги физическим лицам. Очевидный пример — популярные маркетплейсы Wildberries, Ozon, Яндекс Маркет.На этих площадках могут также покупать компании и предприниматели: например, на Яндекс Маркете есть отдельный раздел покупок для бизнеса. Но большая доля покупателей на B2C-площадках — обычные люди. Для такого типа подходит система DST Маркетплейс

B2B — business to business, «бизнес — бизнесу». Площадки, где одни ИП и компании продают товары другим ИП и компаниям. Работают B2B-маркетплейсы так же, как Wildberries и Ozon: площадка привлекает поставщиков и выставляет их товар на витрине. Но сделать заказ сможет только предприниматель или организация. По такой модели работают, например, китайский Alibaba, площадки «Рывок» и «Пульс цен». Для такого типа подходит система DST Мультивендор

C2C — customer to customer, «потребитель — потребителю». Площадка, где физические лица могут покупать друг у друга товары или обмениваться ими. Пользователи сами управляют ценами и определяют время и способ доставки. Самый известный пример C2C-маркетплейса — Авито. Но сейчас предлагать товары и услуги на этой площадке может и бизнес. Для такого типа подходит система DST Маркетплейс

Вопрос к экспертам, помочь определиться с типом площадки, есть три варианта: B2C, B2B, C2C, можно подробнее и на примерах

Вопрос к экспертам, помочь определиться с типом площадки, есть три варианта: B2C, B2B, C2C, можно подробнее и на примерах

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

Создавать площадку с нуля. В этом случае маркетплейс превращается в полноценный стартап — это сложный и дорогой сценарий. Создание маркетплейса с нуля возможно в двух случаях:

1. Бизнес хочет закрыть существующую свободную рыночную нишу. Например, из России ушел маркетплейс БАДов и органической косметики iHerb. Предприниматель может занять эту нишу и запустить новую площадку.

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

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

Создавать площадку с нуля. В этом случае маркетплейс превращается в полноценный стартап — это сложный и дорогой сценарий. Создание маркетплейса с нуля возможно в двух случаях:

1. Бизнес хочет закрыть существующую свободную рыночную нишу. Например, из России ушел маркетплейс БАДов и органической косметики iHerb. Предприниматель может занять эту нишу и запустить новую площадку.

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

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

Создавать площадку с нуля. В этом случае маркетплейс превращается в полноценный стартап — это сложный и дорогой сценарий. Создание маркетплейса с нуля возможно в двух случаях:

1. Бизнес хочет закрыть существующую свободную рыночную нишу. Например, из России ушел маркетплейс БАДов и органической косметики iHerb. Предприниматель может занять эту нишу и запустить новую площадку.

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

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

Создавать площадку с нуля. В этом случае маркетплейс превращается в полноценный стартап — это сложный и дорогой сценарий. Создание маркетплейса с нуля возможно в двух случаях:

1. Бизнес хочет закрыть существующую свободную рыночную нишу. Например, из России ушел маркетплейс БАДов и органической косметики iHerb. Предприниматель может занять эту нишу и запустить новую площадку.

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

У бизнеса есть заблуждение, что для создания собственной площадки с нуля достаточно иметь только идею, — но это не так. Для запуска маркетплейса нужно как минимум разбираться в товарной нише. Приведем пример. Как производитель веников получил помощь правительства для выхода на маркетплейсы

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

После школы Иван переехал в Москву и понял, что в городе сложно найти здоровые продукты. Тогда у него появилась идея создать площадку, где городские жители могли бы покупать качественные и натуральные продукты у фермерских хозяйств.

Иван разбирается в таких товарах, а значит, он:
1. Сможет сформулировать требования для других продавцов.

2. Знает, чем привлечь покупателей.

3. Понимает в ценообразовании и может выстроить грамотную бизнес-модель.

4. Разбирается в особенностях ниши — например, если хранить товары на своем складе, надо поддерживать определенный температурный режим.

Один из краеугольных камней при создании нишевого маркетплейса — это знание ниши. Если его нет, глубинные исследования не помогут.