В эпоху больших данных предприятия также предъявляют более высокие требования к администраторам баз данных. В то же время NoSQL, как новая технология, появившаяся в последние годы, также привлекает все больше внимания. В этой статье будут представлены два основных направления, основанные на работе администратора базы данных, отвечающего за г-на Мэн Сяньяо, SRA, и связанного с этим опыта эксплуатации и обслуживания больших данных: 1. Эволюция архитектуры компании в области хранения KV и проблемы, которые необходимо решить. решается в эксплуатации и сопровождении 2. Как выбрать NoSQL и некоторые мысли о будущем развитии.
Согласно официальной статистике, на сегодняшний день (20 апреля 2018 г.) существует 225 NoSQL-решений, и каждая компания использует очень малую часть из них.Продукты, отмеченные синим цветом на рисунке ниже, являются текущими решениями. .
Происхождение NoSQL
В 1946 году появился первый универсальный компьютер. Но только с появлением RDMBS в 1970 году все нашли универсальное решение для хранения данных. В 21 веке самой сложной проблемой в эпоху DT стала емкость данных, для этого Google и Amazon предложили свои NoSQL-решения, например, Google предложила Bigtable в 2006 году. На технической конференции в 2009 году был официально предложен термин NoSQL, и сейчас существует 225 решений.
Разница между NoSQL и СУБД в основном заключается в двух моментах: во-первых, она обеспечивает гибкость без схемы и поддерживает очень гибкие изменения схемы; во-вторых, масштабируемость, родная СУБД подходит только для отдельных машин и небольших кластеров. И NoSQL распространяется с самого начала, решая проблемы чтения и записи и масштабируемости емкости. Вышеупомянутые два пункта также являются основной причиной NoSQL.
Существует два основных способа распространения: репликация и шардинг. Репликация может решить проблему масштабируемости чтения и высокой доступности (высокой доступности), но не может решить проблему масштабируемости чтения и емкости. Разделение может решить проблему масштабируемости чтения и записи и емкости. Общие решения NoSQL представляют собой комбинацию этих двух.
Разделение в основном решает проблему разделения данных, в основном на основе интервального разделения (например, разделения Hbase Rowkey) и разделения на основе хэшей. Чтобы решить проблему монотонности и сбалансированности распределения хэша, в настоящее время в отрасли в основном используются виртуальные узлы. Codis, описанный ниже, также использует виртуальные узлы. Виртуальные узлы эквивалентны установлению отношений виртуального сопоставления между осколками данных и хост-серверами.
В настоящее время он в основном классифицируется в соответствии с моделью данных и методами доступа NoSQL.
Несколько часто используемых решений NoSQL
Масштаб push-системы Redis показан на рисунке ниже. Ниже представлено несколько проблем, возникающих в процессе эксплуатации и технического обслуживания.
Во-первых, это эволюция технической архитектуры. Getui начинался как служба отправки сообщений для разработчиков приложений. До 2012 года бизнес-объем Getui был относительно небольшим. В то время мы использовали Redis для кэширования и MySQL для сохраняемости. С 2012 по 2016 год, с быстрым развитием бизнеса персональных push-уведомлений, один узел больше не может решить проблему. В случае, если MySQL не может справиться с высоким QPS и TPS, мы разработали решение для сегментирования Redis. Кроме того, мы также разработали собственный клиент Redis, который используется для реализации основных функций кластера, поддержки настраиваемых соотношений чтения/записи, а также мониторинга и изоляции неисправных узлов, медленного мониторинга и проверки работоспособности каждого узла. Однако в этой архитектуре не уделяется должного внимания вопросу эффективности эксплуатации и обслуживания, а также отсутствуют средства эксплуатации и обслуживания.
Когда мы планировали улучшить инструменты эксплуатации и обслуживания, мы обнаружили, что команда Wandoujia открыла исходный код Codis и предоставила нам хороший вариант.
Преимущества использования Codis+
Codis представляет собой архитектуру на основе прокси, поддерживает собственные клиенты, поддерживает операции и мониторинг веб-кластеров, а также интегрирует Redis Sentinel. Это может повысить эффективность нашей работы и обслуживания, а HA также проще во внедрении.
Но в процессе мы также обнаружили некоторые ограничения. Поэтому мы предлагаем Codis+, то есть Codis сделать некоторые улучшения.
Во-первых, применяется схема копирования 2N+1 для решения проблемы единственной главной точки во время сбоя.
Во-вторых, Redis является квазиполусинхронным. Установите порог таким образом, чтобы ведомые устройства были доступны для чтения только в течение 5 секунд.
В-третьих, объединение ресурсов. Расширение ресурсов может быть выполнено путем добавления серверов RegionServers, аналогичных HBase.
Кроме того, существуют возможности для стоек и кросс-IDC. Сам Redis настроен на один компьютерный зал и не учитывает эти проблемы.
Итак, почему бы нам не использовать собственный кластер rRedis? Есть три причины: 1. Собственный кластер, который объединяет функции маршрутизации и пересылки и фактическую функцию управления данными в одну функцию.Если какая-то функция не работает, это приведет к проблемам с данными 2. В большом кластере P2P Процесс Достижение согласованного состояния архитектуры занимает много времени Codis представляет собой древовидную архитектуру, и такой проблемы не существует. 3. Кластер не был одобрен крупной платформой.
Кроме того, что касается Redis, в настоящее время мы рассматриваем Aerospike, новое решение NoSQL, которое мы позиционируем для замены некоторых кластерных Redis. Проблема с Redis заключается в том, что данные находятся в памяти, а это дорого. Мы рассчитываем снизить совокупную стоимость владения с помощью Aerospike. Aerospike имеет следующие особенности:
1. Аэроспейковые данные могут быть помещены в память или SSD и оптимизированы для SSD.
Во-вторых, объединение ресурсов, эксплуатационные расходы и обслуживание продолжают уменьшаться.
3. Поддерживать информацию о стойках и синхронизацию между IDC, но это функция корпоративного уровня.
В настоящее время у нас есть два предприятия, использующих Aerospike для внутренних целей.После фактических измерений мы обнаружили, что одна физическая машина оснащена одним твердотельным накопителем Inter SSD 4600, который может достигать QPS, близкого к 10 Вт. Для услуг с большой пропускной способностью, но низкими требованиями к количеству запросов в секунду вы можете выбрать решение Aerospike для снижения совокупной стоимости владения.
В ходе эволюции NoSQL мы также столкнулись с некоторыми проблемами в работе.
Стандартная установка
Мы разделились на три части: стандартизация ОС, стандартизация файлов и каталогов Redis, стандартизация параметров Redis, все реализовано с помощью saltstack + cmdb;
Приспосабливаясь к расширению и сужению
В ходе непрерывного развития технической архитектуры также возрастает сложность расширения и сжатия, что является одной из причин облегчения CODIS. Конечно, если вы выберете Aerospike, соответствующая операция будет очень простой.
Выполняйте качественную работу по мониторингу и снижайте затраты на эксплуатацию и техническое обслуживание
Большинству студентов, изучающих эксплуатацию и техническое обслуживание, следует внимательно прочитать "SRE: Google Operation and Maintenance Secrets". В нем предлагается множество очень ценных методологий на теоретическом и практическом уровнях, и мы настоятельно рекомендуем его.
Сложность push-мониторинга Redis
Три архитектуры кластера: собственная разработка, codis2 и codis3.Эти три архитектуры собирают данные по-разному.
Существует три типа объектов мониторинга: кластеры, экземпляры и хосты.Метаданные необходимы для поддержания логических связей и их глобального агрегирования.
Три персонализированные конфигурации: push-кластер Redis, для некоторых кластеров требуется несколько копий, а для некоторых нет. Некоторые узлы разрешают полный кеш, а некоторые узлы не разрешают полный. Существуют также стратегии постоянства.Некоторые не обеспечивают постоянство, некоторые обеспечивают постоянство, а некоторые используют постоянство + внешнее резервное копирование.Эти бизнес-характеристики предъявляют высокие требования к нашей гибкости мониторинга.
Zabbix — очень полная система мониторинга, и я использую ее в качестве основной платформы системы мониторинга более трех лет. Но у него есть два недостатка: во-первых, он использует MySQL в качестве внутреннего хранилища, а у TPS есть верхний предел; во-вторых, он недостаточно гибок. Например, если поставить кластер на сотню машин, агрегировать показатели очень сложно.
Open-falcon от Xiaomi решает эту проблему, но также создает некоторые новые проблемы. Например, мало функций будильника, не поддерживаются строки, иногда добавляются ручные операции. Позже, когда мы добавили его функционально, мы не столкнулись с большими проблемами.
На рисунке ниже показана платформа для работы и обслуживания.
Первая — это платформа ИТ-аппаратных ресурсов, которая в основном поддерживает физическую информацию об измерении хоста. Например, к какому коммутатору на какой стойке подключен хост, на каком этаже, в какой комнате с оборудованием и т. д., это основа для осведомленности о стойке и кросс-IDC.
Второй — CMDB, который должен поддерживать информацию о программном обеспечении на хосте, какие экземпляры установлены на хосте, к каким кластерам принадлежат экземпляры, какие порты мы используем и какие персонализированные конфигурации параметров имеют эти кластеры, включая различные аварийные сигналы. механизмы, все из которых реализованы через CMDB. Потребитель данных CMDB включает в себя систему мониторинга grafana и программу сбора данных, а программа сбора разработана нами. Таким образом, данные CMDB оживут. Если есть только статические данные без потребителя, данные будут несогласованными.
Система мониторинга grafana объединяет несколько данных IDC, и нам нужно каждый день смотреть на большой экран для работы и обслуживания.
Slatstack для автоматизации публикации, стандартизации и повышения производительности.
Программа сбора разработана нами и адаптирована к особенностям бизнеса компании. Так же есть ELK (без логстача, с файлбитом) в качестве центра логов.
Через вышеперечисленное мы строим толчок всей системы мониторинга.
Расскажем о нескольких ямах, возникших в процессе строительства.
1. Сброс master-slave приведет к взрывному давлению на хост-узле, и главный узел не сможет предоставлять услуги.
Есть много причин для сброса master-slave.
Версия Redis низкая, а вероятность сброса master-slave высока. Вероятность сброса master-slave у Redis 3 намного ниже, чем у Redis 2. Redis 4 поддерживает добавочную синхронизацию после перезапуска узла, что является большим количеством улучшений в самом Redis.
У нас сейчас в основном используется 2.8.20, относительно несложно произвести из мастера сброс.
Сброс Redis «ведущий-ведомый» обычно запускается одним из следующих условий.
1. Repl-backlog-size слишком мал, по умолчанию 1M, если у вас большое количество записей, то этот буфер легко разбить; 2. repl-timeout, Redis master и slave пингуются каждые десять секунд по по умолчанию, 60 секунд Если пинг не протолкнут, мастер-слейв будет сброшен.Причина может быть в джиттере сети, слишком большое общее давление узла, и он не может ответить на этот пакет и т.д.; 3. tcp -baklog, по умолчанию 511. По умолчанию операционная система ограничена значением 128. Это значение может быть умеренно увеличено, мы увеличиваем его до 2048. Это может быть отказоустойчивым для потери сетевых пакетов.
Выше приведены причины сброса master-slave, а последствия сброса master-slave очень серьезные. Давление мастера взорвалось, и услуга не могла быть предоставлена, и бизнес установил этот узел как недоступный. Если время отклика станет больше, это повлияет на узлы всех хостов, на которых находится мастер.
Во-вторых, узел слишком большой, что отчасти вызвано человеческими причинами. Во-первых, низкая эффективность разделения узлов, что намного медленнее, чем рост объема бизнеса компании. Кроме того, слишком мало осколков. Наших шардов 500, codis 1024, codis native 16384, слишком мало шардов тоже проблема. Если вы создаете самостоятельно разработанное распределенное решение, вы должны увеличить количество сегментов, чтобы развитие бизнеса не превзошло ваши ожидания. После того, как узел станет слишком большим, время сохраняемости увеличится. Наш узел 30G должен быть постоянным, а оставшаяся память хоста должна быть больше 30G. В противном случае использование Swap приведет к значительному увеличению времени сохранения хоста. Для сохранения узла 30G может потребоваться 4 часа. Чрезмерная нагрузка также вызовет сброс ведущий-ведомый, вызывая цепную реакцию.
Что касается ям, с которыми мы столкнулись, давайте поделимся несколькими практическими кейсами.
Первый случай — это сброс master-slave. Эта ситуация произошла за два дня до праздника Весны, который является пиковым периодом бизнеса по продвижению новостей. Кратко восстановим сценарий отказа. Во-первых, крупномасштабная доставка сообщений приводит к увеличению нагрузки, затем увеличивается нагрузка на Redis Master, TCP-пакеты задерживаются, а ОС приводит к потере пакетов. теряется, срабатывает repl-timeout на 60 секунд порог, мастер и слейв сбрасываются. В то же время из-за слишком большого размера узлов насыщенность Swap и IO близка к 100%. Решение очень простое, сначала отключаем мастер от слейва. Первая причина сбоя заключается в том, что параметры являются необоснованными, большинство из которых являются значениями по умолчанию, а вторая заключается в том, что узел слишком велик, чтобы усилить эффект сбоя.
Второй случай — это проблема, с которой недавно столкнулся CODIS. Это типичная сцена неисправности. После зависания хоста CODIS открывает переключатель master-slave, и мастер не будет затронут после основного коммутатора, но мы обнаружим, что он не сможет подобраться, и если мы не сможем его подобрать. Эту неисправность тоже не сложно проверить, на самом деле параметр выставлен слишком маленьким, что связано со значением по умолчанию. Ведомый Из процесса отрисовки основного узла новые данные остаются в главном буфере.Если ВЕДОМЫЙ не был вытащен, главный буфер превышает верхний предел, что приведет к сбросу лорда, входу в мертвый цикл.
На основе этих случаев мы составили список лучших практик.
1. Настройте соответствие ЦП. Redis — это точечная структура с одним компьютером, и несовместимость повлияет на эффективность ЦП.
Во-вторых, размер узла контролируется на уровне 10G.
3. Желательно, чтобы оставшаяся память хоста была больше максимального размера узла + 10G. Сброс Master-Slave должен иметь одинаковый объем памяти, этого должно быть достаточно, если недостаточно, используя Swap, трудно выполнить успешный сброс.
В-четвертых, старайтесь не использовать Swap. 500 миллисекунд для ответа на запрос не так хороши, как зависание.
5. tcp-backlog, repl-backlog-size и repl-timeout умеренно увеличены.
6. Ведущее устройство не выполняет постоянство, а ведомое устройство выполняет AOF + сброс времени.
Наконец, некоторые личные мысли и предложения. Чтобы выбрать NoSQL, который вам подходит, есть пять принципов выбора:
1. Бизнес-логика. Прежде всего, вы должны понимать свои собственные бизнес-характеристики, например, если это тип КВ, ищите его в КВ, если это графический тип, ищите его в графическом типе, чтобы диапазон был снижается на 70%-80%.
2. Нагрузочные характеристики, QPS, TPS и время отклика. Выбирая NoSQL-решение, вы можете оценить по этим показателям, сколько показателей производительности может достичь одна машина при определенной конфигурации? С Redis все в порядке с одним запросом в секунду 400 000–500 000, когда хоста достаточно.
3. Шкала данных. Чем больше объем данных, тем больше вопросов необходимо рассмотреть и тем меньше избирательность. На уровне сотен терабайт или петабайт почти нет выбора, какова система Hadoop.
4. Можно ли контролировать затраты на эксплуатацию и техническое обслуживание и доступность, а также можно ли их легко увеличить или уменьшить.
5. Другие. Например, есть ли успешные кейсы, есть ли полные документы и сообщества, есть ли официальная или корпоративная поддержка. Мы можем позволить другим наступить на яму, а можем ее сгладить, ведь цена того, чтобы наступить на яму самостоятельно, все равно достаточно высока.
Вывод: По поводу определения NoSQL в Интернете ходил анекдот: от знать SQL в 1980-м, до Не только SQL в 2005-м, до сегодняшнего No SQL! Развитие Интернета сопровождается обновлением технических концепций и улучшением сопутствующих функций. За технологическим прогрессом стоит постоянное обучение, тщательное мышление и неустанные усилия каждого технического человека.