При рассмотрении случаев использования NoSQL, таких как хранение пар ключ-значение, MySQL оказывается превосходящим с точки зрения производительности, простоты использования и стабильности.
MySQL — это надежная система с большим количеством онлайн-материалов, охватывающих все: от основных операций и устранения неполадок до репликации и различных моделей использования.
Это дает MySQL преимущество перед более молодыми системами NoSQL, у которых нет такого опыта.
В последние годы системы NoSQL стали мейнстримом.
Многие разработчики рассматривают системы NoSQL, такие как MongoDB, Cassandra, Redis или Hadoop, как лучший вариант для создания своих приложений, считая их единым семейством продуктов, которые обесценивают ценность старых систем SQL. Часто решение использовать базу данных NoSQL основано на обмане или ошибочном представлении о том, что реляционные базы данных не могут обеспечить такую же производительность, как базы данных NoSQL. Когда дело доходит до выбора базы данных, инженеры часто упускают из виду эксплуатационные расходы, а также соображения стабильности и технологической зрелости.
Чтобы узнать больше об ограничениях и недостатках различных систем NoSQL (а также SQL), прочтите серию статей Jepsen Project, опубликованных на Aphyr.com. В этой статье мы объясним, почему мы считаем, что использование MySQL для хранения пар ключ-значение лучше, чем большинство специализированных систем NoSQL, а также предоставим инструкции по использованию MySQL.
Определение сайтов Wix
Когда кто-то нажимает ссылку на сайте Wix, его браузер отправляет HTTP-запрос на сервер Wix с адресом сайта.Это происходит с премиум-сайтом Wix, имеющим собственный домен (например, domain.com), и с бесплатным сайтом на субдомене Wix (например, user.wix.com/site).
Сервер должен распознать запрошенный сайт по адресу сайта, выполнив поиск пары «ключ-значение» для пары «сайт-URL».
В следующем обсуждении мы будем называть URL-адрес «маршрутом».
Таблица маршрутов используется для преобразования адреса сайта в объект сайта.
Поскольку для доступа к сайту можно использовать несколько путей, существует связь «многие к одному».
Когда сайт найден, приложение загружает его для работы с ним.
Объект сайта, в свою очередь, имеет сложную структуру, включающую два списка дочерних объектов — различных сервисов, используемых сайтом.
Ниже приведен пример модели нашего объекта.
Здесь мы предполагаем, что используется стандартная база данных SQL с нормализованной структурой: 
При обновлении сайта с помощью традиционной нормализованной модели нам необходимо использовать транзакцию для обновления нескольких таблиц, чтобы обеспечить целостность данных (обратите внимание, что транзакция использует блокировку на уровне базы данных, которая предотвращает одновременную запись, а иногда и чтение из задействованных таблиц).
Продолжая использовать эту модель, мы, вероятно, получим ключ SERIAL в каждой таблице, внешние ключи и индекс в поле URL таблицы маршрутов.
Однако моделирование данных на основе нормализованной схемы сопряжено с рядом сложностей: • блокировки ограничивают доступ к таблице, поэтому при больших объемах данных это может ограничить нашу производительность; • чтение объекта требует либо нескольких SQL-запросов (в нашем случае 4), либо использования JOIN — и это тоже влияет на задержку; • ключи с атрибутом SERIAL требуют блокировки, что снова ограничивает производительность записи.
Эти проблемы ограничивают пропускную способность и распараллеливание запросов, которые MySQL (или любая другая система SQL) может предоставить нам.
Из-за этих недостатков, а также того факта, что это по сути пара ключ-значение, многие разработчики предпочитают искать решение NoSQL, которое обеспечивает лучшую производительность и распараллеливание, даже за счет стабильности, целостности и доступности.
В Wix мы обнаружили, что MySQL при творческом использовании в качестве хранилища значений ключей может работать лучше, чем MySQL с нормализованной моделью данных (см.
выше), а также лучше, чем большинство систем NoSQL. Наша текущая система обеспечивает параметры масштабирования, пропускной способности, распараллеливания запросов и задержки, которые сделали бы честь любой системе NoSQL. Вот некоторые данные из нашей системы: • активная установка на трёх дата-центрах (актив-актив-актив); • пропускная способность около 200 000 об/мин; • таблица маршрутов имеет объем около 100 000 000 записей, 10 ГБ дискового пространства; • таблица сайтов содержит около 100 000 000 записей, 200 ГБ дискового пространства; • средняя задержка чтения – 1,0-1,5 миллисекунды (реально 0,2-0,3 мс в одном дата-центре).
Обратите внимание, что задержка составляет около 1,0 мс.
считается впечатляющим в большинстве систем «ключ-значение», включая облачные системы и системы с открытым исходным кодом.
И мы добились этого с помощью MySQL (самой простой системы SQL, как принято считать).
Вот диаграмма, которую мы используем: 
Все поля, которые не используются в качестве условий запроса, свернуты в одно поле большого двоичного объекта (текстовое поле site_data).CREATE TABLE `routes` ( `route` varchar(255) NOT NULL, `site_id` varchar(50) NOT NULL, `last_update_date` bigint NOT NULL, PRIMARY KEY (`key`), KEY (`site_id`) ) CREATE TABLE `sites` ( `site_id` varchar(50) NOT NULL, `owner_id` varchar(50) NOT NULL, `schema_version` varchar(10) NOT NULL DEFAULT '1.0', `site_data` text NOT NULL, `last_update_date` bigint NOT NULL, PRIMARY KEY (`site_id`) ) /*ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=16*/;
Он включает в себя таблицы подобъектов, а также любые поля самого объекта таблицы.
Обратите внимание, что мы не используем SERIAL-ключи; вместо этого мы используем поле VARCHAR(50), содержащее созданные пользователем переменные GUID (подробнее об этом в следующем разделе).
Ниже приведен запрос, который мы используем, он имеет высокую пропускную способность и низкую задержку: select * from sites where site_id = (
select site_id from routes where route = ?
)
Здесь сначала выполняется запрос к таблице маршрутов с использованием уникального индекса, запрос должен возвращать только одно значение.
Затем мы сканируем сайты по первичному ключу, снова ища одно значение.
Вложенный синтаксис позволяет обрабатывать оба запроса SQL за один вызов базы данных.
Результат, показанный выше, занимает примерно 1 мс.
Стабильная работа в условиях высокой посещаемости и высокой частоты обновлений.
Обновления являются полутранзакционными, даже без использования транзакций.
Это становится возможным благодаря тому, что мы заходим на весь сайт одной командой INSERT и пока мы не внесем данные в маршруты, запросы их не обнаружат. То есть, когда мы сначала вводим данные сайта, а затем данные пути, мы уверены в целостности наших данных даже в пограничной ситуации, пока наши данные в таблице сайтов не связаны.
Инструкции по использованию MySQL в качестве системы NoSQL Используя опыт, полученный на примере выше (и других подобных кейсах от Wix), мы разработали краткий список рекомендаций по использованию MySQL в качестве NoSQL-системы.
Главное, что следует помнить при использовании MySQL в качестве системы NoSQL, — избегать блокировок на уровне базы данных и сложных запросов.
• Не используйте транзакции, требующие блокировок.
Вместо этого используйте транзакции внутри приложения; • не используйте SERIAL-ключи.
Такие ключи влекут за собой блокировки и усложняют конфигурацию «активный-активный»; • использовать уникальные ключи, сгенерированные клиентами.
Мы используем GUID. Оптимизируя структуру чтения, обратите внимание на несколько дополнительных рекомендаций: • не проводить нормализацию; • если поле есть, оно должно быть проиндексировано.
Если поле индекса не требуется, сохраните его в одном поле BLOB/TEXT (например, JSON или XML); • не используйте внешние ключи; • спроектируйте структуру так, чтобы по требованию можно было прочитать одну строку; • не используйте оператор ALTER TABLE. Эти команды влекут за собой блокировку и периоды временной неработоспособности.
Вместо этого используйте передачу данных Live Migration. При запросе данных: • поиск записей по первичному ключу или индексу; • не используйте JOIN; • не используйте функции агрегирования; • запускать функции проверки (BI, интеллектуальный анализ данных) на репликах, а не на голове.
Мы планируем написать еще одну статью, где более подробно расскажем о передаче данных и транзакциях Live Migrations через приложение.
Вы можете мыслить по-новому
Это, пожалуй, самый важный вывод из этой статьи.Замечательно использовать MySQL в качестве системы NoSQL, хотя она изначально не была разработана.
Как показано в этой статье, в качестве примера можно использовать MySQL для работы с парами ключ-значение вместо систем NoSQL, специально разработанных для этой цели.
В Wix мы выбрали MySQL для пары «ключ-значение» (и многого другого), потому что он прост в использовании, прост в управлении и имеет отличную экосистему.
В качестве бонуса он обеспечивает задержку, пропускную способность и скорость распараллеливания, которые почти превосходят большинство систем NoSQL. Главный архитектор программного обеспечения для дизайнера Создание сайта на Wix , Йоав Авраами Оригинальная статья: Блог инженеров Wix Теги: #MySQL #NoSQL #хитрости с mysql #wix #MySQL #NoSQL
-
Факты О Беспроводных Сетях
19 Oct, 24 -
Файнман, Ричард Филлипс
19 Oct, 24 -
Скажите Пару Слов О Локальном Поиске
19 Oct, 24 -
Гены, Которые Просыпаются После Смерти
19 Oct, 24 -
Игрушка Для Кошек С Питанием От Usb
19 Oct, 24
