benchANT compares MongoDB and ScyllaDB architectures, with a focus on what the differences mean for performance and scalability При выборе базы данных NoSQL варианты могут быть подавляющими. Одним из самых популярных вариантов является MongoDB, известный своей простотой использования. В докладе рассматривается технический аспект обеих баз данных, сравнивая их архитектуру с независимой, технической точки зрения. Бенчатка Как MongoDB, так и ScyllaDB обещают высокодоступную, производительную и масштабируемую архитектуру. Но способ, которым они достигают этих целей, значительно отличается от того, что вы могли бы подумать на первый взгляд. Например, отчет о опыте показывает, как ScyllaDB может легко работать на spot-инстанциях AWS EC2 благодаря его распределенной архитектуре, в то время как распределенная архитектура MongoDB сделала бы это очень сложной задачей. Чтобы подчеркнуть эти различия, мы предлагаем углубленное обсуждение внутренней архитектуры хранения и распределенных архитектур, позволяющих высокую доступность и горизонтальную масштабируемость. Мы также только что выпустили сравнительный показатель, количественно оценивающий влияние этих различий. Note: Подробнее о DynamoDB vs MongoDB Benchmark Summary Скачать этот сравнительный отчет Read the DynamoDB vs MongoDB Benchmark Summary Подробнее о DynamoDB vs MongoDB Benchmark Summary Download this Comparison Report Скачать этот сравнительный отчет Обзор архитектуры хранилища MongoDB против ScyllaDB Обе базы данных реализованы в C++ и рекомендуют использование файловой системы XFS. Кроме того, MongoDB и ScyllaDB основаны на , Commit Log в терминологии ScyllaDB и Oplog в терминологии MongoDB. С записью-передовой записью все операции записываются в таблицу журналов, прежде чем операция будет выполнена. запись-передовой запись служит источником для воспроизведения данных в другие узлы, и она используется для восстановления данных в случае сбоев, потому что возможно «переиграть» операции для восстановления данных. Концепция writing-ahead-logging MongoDB использует индекс B+-Tree (Wired Tiger) для хранения и извлечения данных. Индексы B+-Tree являются сбалансированными структурами данных дерева, которые хранят данные в сортированном порядке, что облегчает выполнение запросов на основе диапазона. MongoDB поддерживает несколько индексов в коллекции, включая индексы соединения, текстовые индексы и геопространственные индексы. Индексирование элементов массивов и встраиваемых полей, позволяющих эффективно задавать запросы на сложные структуры данных, также возможно. ScyllaDB разделяет данные на фрагменты, присвоив фрагмент общих данных в узле конкретному процессору, а также связанную с ним память (RAM) и постоянное хранилище (например, NVMe SSD). Внутренний хранилищный двигатель ScyllaDB следует концепции записи записей, применяя дневник постоянного комментирования диска вместе с запоминающимися на основе памяти, которые с течением времени расплавляются на диск. ScyllaDB поддерживает первичные, вторичные и композитные индексы, как локальные по узлам, так и глобальные по кластерам. Первичный индекс состоит из кольца хеширования, где хранятся хешированный ключ и соответствующий раздел. И внутри раздела, ScyllaDB находит ряд в сортированной струк Эти различные архитектуры хранения приводят к различному использованию имеющегося аппаратного обеспечения для обработки рабочей нагрузки. MongoDB не привязывает внутренние нити к имеющимся ядрам CPU, но применяет не связанный подход к распределенным нитям к ядрам. Архитектуры процессора, это может вызвать ухудшение производительности, особенно для больших серверов, потому что нити могут быть динамически присвоены ядрам на разных розетках с различными узлами памяти. что позволяет прикреплять ответственные нити к конкретным ядрам и избегает переключения между различными ядрами и пространствами памяти. Вследствие этого, ключ шард должен быть тщательно выбран, чтобы обеспечить равномерное распределение данных по шардсам и предотвратить горячие шардсы. который обеспечивает встроенные приоритетные классы для латентных и нечувствительных запросов, а также скоординированное планирование I/O через фрагменты на одном узле для максимизации производительности диска. На основе числа Shard per core подход I/O расписание ScyllaDB позволяет пользователю контролировать, должны ли данные находиться в кэше DB или обходить его для редко доступных разделов. ScyllaDB позволяет клиенту добраться до узла и ядра CPU (shard), которое владеет данными. Это обеспечивает более низкую задержку, последовательную производительность и идеальное балансирование нагрузки. ScyllaDB также обеспечивает «приоритетность рабочей нагрузки», которая предоставляет пользователю различные SLA для разных рабочих нагрузок, чтобы гарантировать более низкую задержку для определенных, критических рабочих нагрузок. Распределенная архитектура MongoDB — два режима работы для высокой доступности и масштабируемости Архитектура баз данных MongoDB предлагает два режима кластера, которые описаны в следующих разделах: кластер с набором реплик нацелен на высокую доступность, в то время как кластер с разломками на горизонтальную масштабируемость и высокую доступность. Replica Set Cluster: высокая доступность с ограниченной масштабируемостью Архитектура MongoDB обеспечивает высокую доступность благодаря концепции наборов реплик. Наборы реплик MongoDB следуют концепции первичных-вторичных узлов, где только первичный обрабатывает операции WRITE. Вторичные держат копию данных и могут быть включены для обработки операций READ только. Распределение общего набора реплик состоит из двух вторичных, но дополнительные вторичные могут быть добавлены для увеличения доступности или масштабирования тяжелых рабочих нагрузок. MongoDB поддерживает до 50 вторичных в пределах одного набора реплик. Вторичные будут выбраны в качестве первичных в случае неудачи на прежнем первичном. Что касается географического распределения, MongoDB поддерживает географически распределенные развертывания наборов реплик для обеспечения высокой доступности в случае сбоев в центрах обработки данных.В этом контексте вторичные экземпляры могут быть распределены по нескольким центрам обработки данных, как показано на следующем рисунке. Sharded Cluster: горизонтальная масштабируемость и высокая доступность с оперативной сложностью MongoDB поддерживает горизонтальное масштабирование, разделяя данные на несколько первичных экземпляров, чтобы справиться с рабочими нагрузками с интенсивностью записи и растущими размерами данных.В раздробленном кластере каждый набор реплик, состоящий из одного первичного и нескольких вторичных, представляет собой раздробленный набор.Поскольку MongoDB 4.4 вторичные также могут быть использованы для обработки запросов на чтение с помощью опции хеджированного чтения. Для того чтобы включить sharding, необходимы дополнительные типы узлов MongoDB: Инстанция mongos действует как маршрутизатор запросов, предоставляя интерфейс между клиентскими приложениями и раздробленным кластером. В результате клиенты никогда не общаются напрямую с фрагментами, а всегда через маршрутизатор запросов. Поиск маршрутизаторов (Mongos) Рекомендуется развертывать несколько маршрутизаторов запросов, чтобы обеспечить доступность кластера, потому что маршрутизаторы запросов являются прямым интерфейсом для драйверов клиента. Нет ограничения на количество маршрутизаторов запросов, но поскольку они часто общаются с конфиг-серверами, следует отметить, что слишком много маршрутизаторов запросов может перегружать конфиг-серверы. Конфиг-серверы хранят метаданные фрагментированного кластера, включая состояние и организацию для всех данных и компонентов. Метаданные включают в себя список частей на каждой фрагменте и диапазоны, которые определяют фрагменты. Конфиг-серверы должны быть развернуты как набор реплик, чтобы обеспечить высокую доступность. Sharding данных в MongoDB осуществляется на уровне коллекции, и коллекция может быть sharded на основе shard key. MongoDB использует shard key, чтобы определить, какие документы принадлежат к какой shard. Общие выборы shard key включают в себя поле _id и поле с высокой кардинальностью, такой как временная печать или ID пользователя. MongoDB поддерживает три стратегии sharding: range based, hash based и zone based. Сортированные разделы разделяют документы по шармам в соответствии с значением ключа шарма. Это сохраняет документы с значениями ключа шармам близко друг к другу и хорошо работает для запросов, основанных на диапазоне, например, на данных временной серии. Сортировка с шармами гарантирует равномерное распределение записей по шармам, что благоприятствует записи рабочих нагрузок. Сортировка с зонами позволяет разработчикам определять правила настраивания, например, чтобы убедиться, что наиболее релевантные данные находятся на шармах, которые географически близки к серверам приложений. Кроме того, раздробленные кластеры могут быть развернуты в географически распределенной настройке для преодоления сбоев в центрах обработки данных, как показано на следующем рисунке. Архитектура ScyllaDB – мультипримарная для высокой доступности и горизонтальной масштабируемости В отличие от MongoDB, ScyllaDB не следует классической архитектуре RDBMS с одним первичным узлом и несколькими вторичными узлами, но использует децентрализованную структуру, где все данные систематически распределяются и воспроизводятся по нескольким узлам, образуя кластер. Кластер - это совокупность взаимосвязанных узлов, организованных в виртуальную архитектуру кольца, по которому распределяются данные. Кольцо подразделяется на vNodes, которые представляют собой ряд токенов, присвоенных физическому узлу, и реплицируются по физическим узлам в соответствии с фактором репликации, установленным для ключевого пространства. Все узлы считаются равными, в многоосновном смысле. Без определенного лидера, кластер не имеет единой точки сбоя. Узлы могут быть индивидуальными на местах серверами, или виртуальными серверами (публичными облачными инстанциями), состоящими из подгруппы оборудования на более крупном физическом сервере. На каждом узле данные далее разделяются на части. Части работают как Все узлы общаются друг с другом через Этот протокол решает, в каком разделе записываются какие данные, и ищет записи данных в правом разделе с помощью индексов. Протокол Гоголя Когда речь заходит о масштабировании, архитектура ScyllaDB предназначена для легкого горизонтального шарджирования на нескольких серверах и регионах. Шарджирование в ScyllaDB осуществляется на уровне таблицы, и таблицу можно шарджировать на основе ключа раздела. Ключ раздела может быть одной колонной или составной частью нескольких колонн. ScyllaDB также поддерживает шарджирование на основе диапазона, где ряды распределяются по шарджирам на основе диапазона значений ключа раздела, а также шарджирование на основе хеш для равномерного распределения данных и избежания горячих точек. Кроме того, ScyllaDB позволяет реплицировать данные по нескольким центрам обработки данных для более высокой доступности и более низких задержек.В этой многоцентральной или многорегиональной настройке данные между центрами обработки данных реплицируются асинхронно. С клиентской стороны приложения могут или не могут быть осведомлены о развертывании нескольких центров обработки данных, и разработчик приложений должен решать, насколько осведомлен об этом центр обработки данных (центры обработки данных).Это может быть конфигурировано с помощью параметров последовательности чтения и письма, которые определяют, выполняются ли запросы в отношении одного центра обработки данных или во всех центрах обработки данных. Сравнительная точка зрения на масштабируемость распределенных архитектур MongoDB и ScyllaDB Когда дело доходит до масштабируемости, необходимо учитывать существенно разные подходы к распространению как ScyllaDB, так и MongoDB, особенно для самоуправляемых кластеров, работающих на местах или на IaaS. Архитектура MongoDB позволяет легко масштабировать трудовые нагрузки с большим числом, увеличивая количество вторичных наборов в наборе реплик. Тем не менее, для масштабирования рабочих нагрузок с заметной пропорцией записи, наборы реплик необходимо преобразовать в набор реплик с разломками, и это приводит к нескольким вызовам. Во-первых, требуются две дополнительные услуги MongoDB: n маршрутизаторы запросов (mongos) и набор реплик конфиг-серверов для обеспечения высокой доступности. Следовательно, значительно больше ресурсов требуется, чтобы позволить разломки в первом месте. Кроме того, операционная сложность явно возрастает. Например, набор реплик с тремя разломами требует набора реплик из трех инстанций монгоса, набор реплик из трех конфиг-серверов и трех разломов – каждый из которых состоит из одного первичного и по крайней мере двух вторичных. Второй вызов заключается в перераспределении данных в раздробленном кластере. Здесь MongoDB применяет постоянно выполняемую фоновую задачу, которая автономно запускает перераспределение данных по раздробленным группам. Перераспределение происходит не сразу, как только к кластеру добавляется новая раздробленная группа, а когда достигаются определенные внутренние пороги. Следовательно, увеличение количества раздробленных групп сразу же масштабирует кластер, но может иметь задержанный эффект масштабирования. До MongoDB версии 5.0, сами инженеры MongoDB рекомендуют не раздроблять, а скорее масштабировать вертикально с большими машинами, если это возможно. Скалирование кластера ScyllaDB сравнительно легко и прозрачно для пользователя благодаря многоосновной архитектуре ScyllaDB. Здесь каждый узел равен, и никакие дополнительные услуги не нужны для масштабирования кластера до сотен узлов. Кроме того, разделение данных запускается, как только новый узел добавляется в кластер. В этом контексте ScyllaDB предлагает четкие преимущества перед MongoDB. Во-первых, благодаря последовательному хашированию, данные не нужно распределять по всему кластеру, только по подгруппе узлов. Во-вторых, разделение начинается с добавления нового узела, что облегчает сроки масштабирования. Это важно, так как разделение добавляет некоторую дополнительную нагрузку на кластер и следует избегать на этапах пикового рабочего Основные различия масштабируемости обобщены в следующей таблице: Выводы и Outlook Если сравнивать два распределенных базы данных, вы всегда обнаруживаете некоторые параллели, но также многочисленные значительные различия. . Обе базы данных обращаются к похожим случаям использования и имеют схожую стратегию продукта и сообщества. Но когда дело доходит до технической стороны, вы можете увидеть разные подходы и фокус. Обе базы данных построены для обеспечения высокой доступности через распределенную архитектуру. Но когда дело доходит до целевых рабочих нагрузок, MongoDB позволяет легко начать с одноузловых или репличных комплектов развертываний, которые хорошо подходят для малых и средних рабочих нагрузок, в то время как решение проблем с большими нагрузками и наборами данных становится проблемой из-за технической архитектуры. NoSQL ScyllaDB против MongoDB ScyllaDB четко справляется с рабочими нагрузками, критическими для производительности, которые требуют легкой и высокой масштабируемости, высокой пропускной способности, низкой и стабильной задержки и всего в многоцентровом развертывании.Это также демонстрируют случаи интенсивного использования данных компаний, таких как Discord, Numberly или TRACTIAN, которые перешли из MongoDB в ScyllaDB для успешного решения проблем с производительностью. Чтобы предоставить дополнительное представление о своих возможностях в области производительности, мы предоставляем прозрачное и воспроизводимое сравнение производительности в отдельном отчете, который исследует производительность, масштабируемость и затраты MongoDB Atlas и ScyllaDB Cloud. Дополнительное сравнение ScyllaDB vs. MongoDB Подробности Смотреть полный для расширенной версии этого технического сравнения, включая детали сравнения: BenchANT MongoDB vs ScyllaDB сравнение Модель данных Язык Query Случаи использования и примеры клиентов Варианты последовательности данных Опыт работы из первых рук
