НовостиОбзорыСобытияIT@WorkРеклама
Идеи и практики автоматизации:

Блог

Как Гугль из MySQL сделал NoSQL F1

На днях крупнейший сайт электронных объявлений Craigslist довел свою БД до трех миллиардов документов. Год назад эта база была перенесена с MySQL на MongoDb, о развитии которой рассказывалось позавчера. В этой связи смотрится крайне интересным свежий анонс Гуглем новой СУБД F1, которая позиционируется как нечто среднее между SQL- и NoSQL-системами, а основана на MySQL.

[spoiler]Точнее, официально F1 позиционируется все же как РСУБД, однако в нее загнано множество NoSQL-фишек. Причина этого в том, что традиционно Гугль использовал MySQL для критически важных для своего рекламного бизнеса задач, однако планетарные масштабы эта СУБД не тянула, и подразделению Google Research была поставлена задача усилить MySQL NoSQL-ем. Проект завершился успешно, и отныне MySQL-сервисы Гугля работают уже под F1 (pdf).

F1 совмещает в себе фичи, характерные для современных NoSQL-систем -- простота обеспечения масштабируемости, отказоустойчивости и шардинга, дешевизна, быстрое выполнение простых запросов, с сильными сторонами РСУБД (качественная поддержка сложных транзакций, разграничение доступа) и параллельным SQL-движком.

Правда, необходимость специфической поддержки распределенных транзакций замедлила время типовой операции записи в F1 в сравнении с MySQL, поэтому схемы эксплуатируемых БД пришлось переделать под новую технологию, да и работающие с ней приложения переписать. Однако затраты стоили того -- теперь масштабирование F1 выполнять в сравнении с MySQL гораздо проще. А вот операции считывания, несмотря на все ухищрения и стыковку SQL и Map Reduce, так и не удалось "побороть", они выполняются существенно медленнее, нежели в MySQL, занимая 5-10 мс. Это впрочем объяснимо -- команды записи буферизуются на клиенте, и затем выполняются в одном rpc-вызове, а со считыванием, которое может быть параллельным, так не выйдет. Ведь это все хозяйство работает, напомню, в мега-системе из пяти ЦОДов, разбросанных по США для обеспечения устойчивости в случае природных катаклизмов.

В качестве NoSQL-движка в F1 задействован Spanner -- серьезно переделанная гуглевская BigTable. Форком Spanner, похоже, стал Megastore -- транзакционный менеджер индексированных записей, ежесуточно обеспечивающий 3 млрд записей и 20 млрд считываний из петабайта данных, размазанных по ЦОДам всего мира. А вот платой за поддержку кросс-ЦОДовской работы стало завышенное (в три раза) требование к аппаратным и системным ресурсам.

Гугль конечно не единственный "орёл" в этой сфере:

- RainStor выпустила SQL + MapReduce систему с недвусмысленным названием RainStor Big Data Analytics on Hadoop (используется например Банком Америки и AT&T, а выросла она из оборонного английского проекта), а затем заключила соглашение с IBM на усиление своей системы корпоративным решением InfoSphere BigInsights;

- Drawn To Scale получила миллион долларов на развитие своей Spire (SQL+NoSQL поверх Hadoop);

- Oracle продвигает свой Oracle Big Data Appliance (распределенная Oracle NoSQL на основе Berkley DB) через Hadoop-дистрибутив Cloudera CDH.