Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them Рабочие нагрузки баз данных с большим числом данных приносят существенно иной набор задач, нежели нагрузки с большим числом данных. Скалирование записей может быть дорогостоящим, особенно если вы платите за операцию и записываете в 5 раз дороже, чем читаете. Закрытие может добавлять задержки и уменьшать пропускную способность Бутылки I/O могут привести к написанию усиления и усложнить восстановление аварий База данных Backpressure может затормозить входящую нагрузку Хотя стоимость имеет значение – во многих случаях – это не тема, которую мы хотим охватывать здесь.Наоборот, давайте сосредоточимся на сложностях, связанных с производительностью, с которыми обычно сталкиваются команды, и обсудим ваши варианты решения этих проблем. Что мы имеем в виду под «тяжелой рабочей нагрузкой по написанию в реальном времени»? Во-первых, давайте проясним, что мы имеем в виду под рабочей нагрузкой «тяжелое в реальном времени написание».Мы говорим о нагрузках, которые: Поглощение большого количества данных (например, более 50 000 OPS) Привлечь больше писать, чем читать Относятся к строгой латентности SLA (например, латентность однозначной миллисекунды P99). В дикой природе они встречаются во всем, от онлайн-игр до бирж в реальном времени. Интернет вещей (IoT) рабочие нагрузки, как правило, включают в себя небольшие, но частые приложения-только записи данных временной серии. здесь, скорость поглощения в первую очередь определяется количеством конечных точек, собирающих данные. Системы записи и мониторинга также имеют дело с частым поглощением данных, но они не имеют фиксированной скорости поглощения.Они могут не обязательно прикрепляться только, а также могут быть склонны к горячим точкам, например, когда одна конечная точка ведет себя неправильно. Онлайн-платформы для игр нуждаются в обработке взаимодействий пользователей в режиме реального времени, включая изменения состояния игры, действия игроков и обмен сообщениями. рабочая нагрузка имеет тенденцию быть резкой, с внезапными всплесками активности. Рабочие нагрузки электронной коммерции и розничной торговли обычно загружены обновлениями и часто включают в себя обработку партий. Эти системы должны поддерживать точные уровни запасов, обрабатывать отзывы клиентов, отслеживать состояние заказов и управлять операциями корзины покупок, которые обычно требуют чтения существующих данных, прежде чем делать обновления. Системы Ad Tech и Real-time Bidding требуют принятия решений в разное время. Эти системы обрабатывают сложную обработку предложений, включая отслеживание результатов аукционов, одновременно отслеживая взаимодействия пользователей, такие как клики и конверсии. Системы фондовой биржи в режиме реального времени должны поддерживать высокочастотные торговые операции, постоянные обновления цен на акции и сложные процессы сопоставления заказов – все это при сохранении абсолютной последовательности данных и минимальной задержки. Далее рассмотрим ключевые архитектурные и конфигурационные соображения, которые влияют на производительность письма. Архитектура хранилища двигателей Выбор архитектуры хранилища фундаментально влияет на производительность записи в базах данных. Существуют два основных подхода: LSM-деревья и B-Деревья. Базы данных, известные тем, что позволяют эффективно обрабатывать письма, такие как ScyllaDB, Apache Cassandra, HBase и Google BigTable, используют Log-Structured Merge Trees (LSM). Эта архитектура идеально подходит для обработки больших объемов письма. Поскольку письма сразу же прикреплены к памяти, это позволяет очень быстро начать хранение. Как только «записка» в памяти заполняется, последние письма промываются на диск в сортированном порядке. Например, вот как выглядит путь написания ScyllaDB: С структурами B-tree каждая записывающая операция требует локализации и модификации узла в дереве – и это включает как последовательный, так и случайный I/O. По мере роста набора данных дерево может требовать дополнительных узлов и перебалансировки, что приводит к большему количеству в/о диска, что может повлиять на производительность. Payload размер Размер полезной нагрузки также влияет на производительность. При небольших полезных нагрузках пропускная способность хороша, но обработка процессора является основным барьером. По мере увеличения размера полезной нагрузки вы получаете более низкую общую пропускную способность, а использование диска также увеличивается. В конечном счете, небольшая запись обычно вписывается во все буферы и все может быть обработано довольно быстро. Именно поэтому легко получить высокую пропускную способность. Для больших полезных нагрузок вам нужно выделить большие буферы или несколько буферов. Чем больше полезных нагрузок, тем больше ресурсов (сеть и диск) требуется для обслуживания этих полезных нагрузок. компрессии Использование диска - это то, что нужно внимательно наблюдать при тяжелой нагрузке на написание.Хотя хранилище постоянно становится дешевле, оно все еще не бесплатно. Сжатие может помочь держать вещи под контролем – поэтому выбирайте стратегию сжатия с умом.Более быстрые скорости сжатия важны для тяжелых рабочих нагрузок, но также учитывайте имеющиеся ресурсы CPU и памяти. Убедитесь, что вы посмотрите на Компрессия в основном разделяет ваши данные на более мелкие блоки (или кусочки), а затем сжимает каждый блок отдельно.При настройке этой настройки осознайте, что более крупные кусочки лучше для чтения, в то время как более мелкие лучше для письма, и учитывайте размер полезной нагрузки. Компрессия Chunk Parameter Сочувствие Для баз данных, основанных на LSM, стратегия сжатия, которую вы выбираете, также влияет на производительность записи. сжатие включает в себя слияние нескольких SSTables в меньшее количество, более организованных файлов, чтобы оптимизировать производительность чтения, восстановить пространство на диске, уменьшить фрагментацию данных и поддерживать общую эффективность системы. При выборе стратегий сжатия вы можете стремиться к усилению с низким числом, что делает считывания максимально эффективными. Или вы можете стремиться к усилению с низким числом, избегая того, чтобы сжатие было слишком агрессивным. (и Кассандра предлагает аналогичные): Несколько стратегий компоновки Стратегия сжатия по размеру (STCS): Запускается, когда в системе достаточно (по умолчанию четыре) SSTables аналогичного размера. Стратегия выровненного сжатия (LCS): система использует небольшие, фиксированные размеры (по умолчанию 160 МБ) SSTables, распределенные по различным уровням. Инкрементальная стратегия сжатия (ICS): Объединяет те же факторы усиления считывания и записи, что и STCS, но фиксирует свою проблему временного усиления пространства в 2 раза, разрывая огромные стебли на SSTable run, которые состоят из сортированного набора меньших (1 ГБ по умолчанию), не перекрывающихся SSTables. Стратегия сжатия временного окна (TWCS): предназначена для данных временных серий. Для рабочих нагрузок, тяжелых по написанию, мы предупреждаем пользователей избегать выровненного сжатия любой ценой.Эта стратегия предназначена для случаев тяжелого использования.Использование ее может привести к сожалеющему 40х усилению написания. Батчин В базах данных, таких как ScyllaDB и Cassandra, парчивание на самом деле может быть немного ловушкой – особенно для тяжелых рабочих нагрузок. Если вы привыкли к реляционным базам данных, парчивание может показаться хорошим вариантом для обработки большого объема записей. Но на самом деле оно может замедлить вещи, если это не сделано аккуратно. В основном, это потому, что большие или неструктурированные партии в конечном итоге создают много координации и сетевой перегрузки между узлами. Вот как думать о пакетировании, когда вы имеете дело с тяжелыми письмами: Batch by the Partition Key: Группировка ваших записей по разделительному ключу, так что партия переходит к узлу координатора, который также владеет данными.Таким образом, координатору не нужно выходить на другие узлы для получения дополнительных данных. Держите партии малыми и целенаправленными: Разделение больших партий на более мелкие по разделу делает вещи эффективными. Это избегает перегрузки сети и позволяет каждому узлу работать только с данными, которыми он владеет. Придерживайтесь незарегистрированных партий: учитывая, что вы следуете предыдущим пунктам, лучше всего использовать незарегистрированные партии. Так что, если вы находитесь в тяжелой ситуации, тщательно структурируйте свои партии, чтобы избежать задержек, которые могут ввести большие, перекрестные партии. Вверх Вверх Мы предложили несколько предупреждений, но не волнуйтесь.Это было легко составить список уроков, полученных, потому что так много команд очень успешно работают с рабочими нагрузками, тяжелыми для записи в режиме реального времени. Если вы хотите узнать больше, вот некоторые первоочередные взгляды от команд, которые справились с довольно интересными сложными задачами: Zillow: потребление записей от нескольких производителей данных, что привело к нарушению порядка, что может привести к неправильным обновлениям Tractian: подготовка к 10-кратному росту высокочастотных данных из IoT-устройств Фанатики: тяжёлые операции по написанию, такие как обработка заказов, корзины покупок и обновления продуктов для этого онлайн-спортивного ритейлера Зиллоу трактат фанатиков Кроме того, взгляните на следующее видео, где мы пойдем в еще большую глубину на эти тяжелые задачи, а также пройдем вас через то, как эти нагрузки выглядят на ScyllaDB.
