Вы здесь: Главная > Заметки > Cassandra. Отказ от SQL

Cassandra. Отказ от SQL

Facebook использует собственноручно разработанное noSQL-решение Cassandra, а Twitter опирается в работе на связку Cassandra и технологии HBase. Это самые известные примеры. Дак о чем я?

К современным веб-проектам предъявляются колоссальные требования по части безопасности и безотказности. Веб-проекты должны выдерживать большие и очень большие нагрузки. Одним из самых трендовых способов увеличить быстродействие системы стал отказ от использования медленных SQL баз данных и переход там, где это возможно, к технологиям noSQL, использующих для хранения данных простые структуры данных вроде «ключ-значение». То, что сложно было представить еще несколько лет назад, стало сейчас настолько очевидным. Ведь для большинства веб-приложений вовсе не нужны все эти множества типов данных, поддерживаемых СУБД, и к тем более средств их выборки.

Часто необходимо просто сохранить информацию и иметь к ней доступ. SQL-запросы, как ни крути, даже при оптимизации выполняются относительно медленно, я бы сказал при реальной нагрузки, просто пизд*ц. Конечно если у вас на сайте не более 5т человек онлайн, то Вам на это насрать. Дак вот вернемся. Для хранения данных зачастую вполне достаточно просто хранить ключ записи и ее значение. Значение — это обычные сериализированные данные, например, в формате JSON или более продвинутой структуре вроде messagePak, Google ProtoBuf или Apache Thrift.

MongoDB пошла еще дальше, реализовав в качестве замены для удобного JSON специальный двоичный формат. Другая разработка — Redis — перевернула понятие key-value-хранилищ, добавив к ним простые, но оказавшиеся эффективными и востребованными списки, хэши и сортированные массивы. Интерфейс доступа к noSQL-базе также максимально прост — обычно это простейшие команды типа get (получить данные по ключу), set (записать данные с ключом), delete (удаляет ключ и его данные), update (обновляет уже существующие данные). На низком уровне такие базы строятся на базе хеш-таблиц и их разновидности — распределенной хеш-таблицы (DHT).

Благодаря этому решения noSQL оказались не только очень быстрыми, но еще и легко масштабируемыми. Свойства DHT такие, что можно присоединять новые серверы постоянно, и такая база будет расти и расти. Столько, сколько надо. При этом в самих приложениях ничего менять не надо, все делается автоматически! Это очень важно, потому что если приложение не может одинаково хорошо работать и на одном, и на тысяче серверов, то оно не масштабируемо. А значит при неожиданно высокой нагрузке, оно ляжет и уже не сможет восстановить работу, даже при покупке новых серверов. В то время как обычные СУБД просто рвутся на части и подпираются костылями, чтобы работать хоть на паре десятков серверов одновременно, практически любое noSQL-решение может спокойно масштабироваться хоть на тысячу серверов. И все это на скоростях более 100 тысяч операций в секунду, над гигабайтами данных и миллионами ключей на обычном железе.