Andrej Gaevskij's List: NoSQL

• Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время
• горизонтальное масштабирование при больших объемах данных
• • производительность каждого отдельного сервера
   
  • не гибкий дизайн логической структуры.
• NoSQL — это «Не только SQL» (Not Only SQL)
• Под масштабируемостью, некоторые могут подразумевать репликацию, так что когда мы говорим о масштабируемости в данном контексте — мы имеем в виду автоматическое распределение данных между несколькими серверами. Такие системы мы называем распределенные базы данных. В них входят Cassandra, HBase, Riak, Scalaris и Voldemort. Это ваш единственный выбор, если вы используете объем данных который не может быть обработан на одной машине или если вы не хотите управлять распределением вручную.
• Не распределенные базы данных включают в себя CouchDB, MongoDB, Neo4j, Redis и Tokyo Cabinet. Данные системы могут служить прослойкой для хранения данных для распределенных систем; MongoDB предоставляет ограниченную поддержку шардинга (sharding), так же как и отдельный проект Lounge для CouchDB, и Tokyo Cabinet может использоваться как система хранения файлов для Voldemort.
• Система ключ/значения сама по себе простая, и не сложная для реализации, но не эффективна, если вы заинтересованы только в запросе или обновлении части данных. Так же трудно реализовать сложные структуры поверх распределенных систем.
• Документо-ориентированные базы данных это по существу следующий уровень систем ключ/значение, позволяющие связывать вложенные данные с каждым ключом. Поддержка таких запросов более эффективна, чем просто возвращение всего BLOB каждый раз.
• Neo4J обладает поистине уникальной моделью данных, храня объекты и связи в качестве узлов и ребер графа. Для запросов, которые соответствуют этой модели (например, иерархических данных) они могут быть в тысячу раз быстрее, чем альтернативные варианты.
• Базы данных хранящие данные в памяти очень, очень быстрые (Redis может выполнять до 100,000 операций в секунду), но не могут работать с данными превышающими размер доступной оперативной памяти. Долговечность (сохранение данных в случае сбоя на сервере или отключения питания) так же может быть проблемой (в новых версиях будет поддержка append-only log). Количество данных которые могут ожидать записи на диск потенциально велико.
• B-деревья используются в базах данных уже очень давно. Они обеспечивают надежную поддержку индексирования, но производительность очень низкая при использовании на машинах с жесткими дисками на магнитных дисках (которые по-прежнему наиболее экономически эффективны), так как происходит большое количество позиционирований головки при записи или чтении данных.

9 more annotations...

• Sharding — дробление базы данных на несколько шардов.
   Shard — один или несколько равнозначных серверов, которые хранят одну и ту же часть данных.
   Config-server — сервер, хранящий мета-информацию в первую очередь о том на каком shard'е какой chunk лежит.
   Chunk — диапазон документов по индексу, например коллекцию hosts можно разбивать по индекс на свойстве url.
   mongos — демон который принимает запросы от клиентов, взаимодействует с нужными shard'ами и config-серверами, и передает готовый ответ клиенту.

• Необходимо думать на этапе проектирования о важных вопросах. И не нужно - о несущественных вопросах: какой язык программирования выбрать, какую базу данных. Особо глупый вопрос - какой фреймворк выбрать, например, на PHP их десятки (доказательства - позже).
• 
  Первые шаги на правильном пути - осознать несущественность этих вопросов и спроектировать каждый из компонентов проекта горизонтально масштабируемым.
• задача сделать так, чтобы ни на одном SQL инстансе, какой бы общей нагрузка ни была, не случился затык по производительности.
• “Разместим соц.сеть на облачном хостере” - стандартное забулуждение
• Memcache применяется для хранения особо часто обновляемой информации, т.е. он хранит ~5% данных из основной SQL базы.
• За счет этого достигается скорость.
• Много непонятных мне споров про RAID. Совершенно не важно, используется RAID или нет. Важно то, наша система избыточного хранения данных выше всего этого. В этом смысл масштабирования - каким бы ни были скоростные характеристики дисков и их надежность, мы просто дублируем споты на разные физические устройства и заведомо обходим любые физические ограничения, которые были ранее или неожиданно возникнут в будущем.
• Ради highload не важно что ставить, только бы работало быстрее аналогов и не глючило.
• Представим, что у нас много серверов. Разобьем их на главные типы: пул MySQL, пул Backend PHP (+отдельные под Cron задачи), пул memcache, пул файловых стораджей, пул веб-балансеров (32 штуки) и т.д.
• Рассмотрим особенности каждого из серверов. Memcache: занимает 70% памяти, где-то 10% CPU, 0% жесткого диска, 50% сетевого интерфейса (сеть должна быть свободной всегда для быстрого отклика). Файловый сторадж: файловый кеш 70% памяти, 0% CPU, 100% жесткого диска, скорость отклика по сети не очень важна.
  
  Очевидна несправедливость: на сервере memcache почти полностью простаивает CPU и жесткий диск, а на файлом сторадже - CPU и сеть. Есть 2 типа сисадминов - правильные (большинство в мире) и не правильные (к ним относится ВКонтакте и я). Первый тип админов, не смотря на описанный выше очевидный простой ресурсов, стремятся разбить все сервера по типам исполняемых ими задач, потюнить ОС и т.д. Их цель - довести производительность главного назначения сервера до максимума. Второй тип админов стремится не дать простаивать ресурсам, объединяя некоторые не конфликтующие процессы на одном физическом сервере. Ну, жалко же, что на файловых стораджах куча памяти и cpu не используются! Туда столько всего полезного можно напихать, типа пассивных реплик любых других хранилищ для повышения общей производительности на отдачу контента.
• В мемкеше хранится, допустим, 5% нужной информации. Все показы профайлов и записи изменений происходят через обращения к memcache, а в фоновом режиме они копируются в основную MySQL базу.

9 more annotations...