dev {highload}. when you should do your own db

"Когда стоит написать свою БД"

Олег КрасновСистемный Архитектор

[email protected]

2013 dev.it-portfolio.net

dev.it-portfolio.net 2

Что такое SEMrush

- Ведущий сервис анализа конкурентов- Позволяет узнать ключевые слова- Позволяет анализировать не только ваши

собственные данные- Сведения об бюджетах конкурентов на

продвижение в поисковиках- Данные о затратах на каждое конкретное

объявление и его содержимое


Как выглядит SEMrush


Картина пользователей

- Рядовые пользователи: более 300 тысяч- Крупные клиенты: более 50

- Интеграторы: более 100


Объёмы данных

- 90 миллионов слов- 10 языковых баз- > 2 миллиардов URL- 30% AdWords объявлений- 3 терабайта актуальных данных- 40 терабайт исторических данных


Характер данных

- Ключевые слова- Числовые данные- URL- Небольшие тексты объявлений


Хорошие примеры

- youtube.com : ~ 30 миллионов слов- wikipedia.org : ~ 20 миллионов слов- t-v-links.blogspot.com : 51 слово- tiffanytunes.com : 28 слов


Распределение данных


Как это было в 2009 году

- MySQL 5.0.76 для хранения посчитанных индексов по всем полям (MyISAM)

- Большие файлы для хранения текстовых данных

- PHP 5.2.x для объединения данных и отдачи отчётов


Что же стало понятно

Наличие прототипа – это прекрасно!


Но присутствовали проблемы

- Очень медленно строилось- Плохо масштабировалось- Для каждого столбца нужен был отдельный

индекс- Занимало излишнее место- Никто не понимал как это было написано


А чего же хотелось

- Быстрой отдачи данных- Асинхронной отдачи данных- Отказоустойчивости- Масштабируемости- Простоты


Может быть SQL

- MySQL : медленное построение- PostgreSQL : схожие проблемы- ORACLE : платный- MSSQL : чуждая среда


Может быть NoSQL

- Redis: первый коммит 22 марта 2009 года- MongoDB: первый релиз версии 9 декабря

2009 года (версия 0.0.3)- Hadoop (версия 0.19.2) – большое

количество серверов


А что же тогда

- Файловая система- Бинарные индексы- Текстовые файлы- Хорошая хэш-функция для поиска- Компактное хранение числовых данных


Пробы пера в файловых системах

- UFS2 + Soft Updates- EXT3(4)- ReizerFS 3- ZFS


Магия файловых систем

- Перелинковка- Устойчивость к потерям данных- Работа на уровне ядра- Стабильность- Простота- Возможность создания виртуальных

устройств


Как это строится

- Основной индекс строится во время сбора данных

- Агрегированные данные строятся после этого

- Параллельно строятся дополнительные индексы

- Затем строятся текстовые индексы


Как это хранится

- Индексы- Тексты- Ранки- Исходники


Что стало понятно в процессе

- Необходимо кэширование результатов- Часто запрашиваемые данные должны

лежать отдельно- Учёт пользователей должен быть отдельно


Как это отдаётся

- JSON- TCP сервер- Для числовых данных event сервера- Для текстового поиска и фильтров сервер

полнотекстового поиска


Что же там внутри

- C- UNIX way- Бинарный поиск- Деревья- Хэш таблицы


Как это хранилось раньше

Индексы

Текстовые данные

US


Как это хранится теперьiSCSI через внутренний сетевой интерфейс


А если будет много запросов


Чего мы достигли

- Производительности: количество обрабатываемых увеличилось на порядок с 3 до 30 миллионов запросов в сутки

- Гибкости: ввод в строй новых отчётов не сопряжён с непреодолимыми трудностями

- Простоты развёртывания- Простоты резервного копирования и

восстановления


Вспомогательные сервисы

- libevent + mmap- Sphinx- Python


Взгляд в будущее

- Новые отчёты- Исторические данные- Увеличение количества баз- Непрерывные обновления


Непрерывные обновления

- Слегка поменять технологию сбора- Написать одну утилиту- Удовлетворённо посмотреть на результат


Выводы из вышесказанного

- Стоит писать свою базу данных- Но если чётко известен объём задачи


Спасибо за внимание!


Будьте на связи

Олег КрасновСистемный архитектор компании SEMrush

[email protected]+7 (962) 700-1771

dev {highload}. when you should do your own db

Documents