Тогда же мы решили, что не станем сразу строить полноценный поисковик, который будет работать рядом с основным. Когда две версии «тяжёлого» веб-сервиса раннюю и позднюю развивают параллельно, второй, как правило, не удается догнать первую. В первой версии постоянно появляются новые фичи, которые во второй просто не успевают реализовывать; в результате новая версия поиска имела бы риск так и не с
Мы начали тестирование HBase с небольшого кластера на 16 машин. Первые тесты были успешными всё работало стабильно и с приемлемой скоростью. Скоро число серверов в кластере увеличилось до 32, а потом и до 50.
Оставалось два варианта Cassandra и HBase. Cassandra обеспечивала большую скорость, но и давала более высокий риск потери данных. У HBase, наоборот, была ниже скорость записи, зато выше надежность. Кроме того, HBase тесно интегрировался с Hadoop. Это и стало для нас решающим аргументом в его пользу.
Нас интересовало удобство использования в наших условиях, скорость и, конечно, стабильность работы. О соответствии последнему критерию можно судить по тому, сколько компаний используют ту или иную таблицу. HyperTable отпал практически сразу, поскольку нас не устроила его стабильность: на тот момент из крупных сервисов его использовал только китайский поисковик Baidu. Установить его на стенд получилось с огромным трудом, что практически гарантировало огромное количество головной боли при использовании (сейчас, по отзывам, он стал значительно более удобным).
Свободно распространяемых клонов BigTable было три: первый HBase, построенный в рамках того же коммьюнити, которое сделало Hadoop, второй HyperTable, и третий опенсорсное решение Cassandra, скопированное с решения Dynamo (которое, в свою очередь, было создано в Amazon по мотивам BigTable).
В итоге, размышляя подобным образом, рано или поздно ловишь себя на мысли «Это же BigTable», так что мы решили исследовать известные Open Source-аналоги.
Далее мы начали думать над тем, как реализовать базу данных с информацией об обкачанных URL-ах. На этом этапе возникало множество вопросов. Например: у нас есть список URL-ов и контент URL-ов стоит ли держать их в одном файле или лучше разбить на два? Логично разбить: ведь контент, в отличие от URL-ов, нужен не всегда. А если мы хотим что-то быстро дописать к этому файлу неужели мы будем для этого проходить по нему, чтобы скопировать его в новое место с новыми изменениями? Напрашивается решение создать рядом ещё один небольшой файл, в который мы допишем новые изменения, и проходить по двум файлам параллельно.
Клоны BigTable: HBase, Hypertable, Cassandra
Конечно, программисты, которые пересаживались на вычислительный кластер из шестидесяти серверов, испытывали эйфорию. Всё то, что раньше программист делал долго и мучительно, то, что выполнялось на серверах по несколько недель, теперь программировалось за день и выполнялось в течение 15 10 минут. Конечно, когда практически все программисты пересели на Hadoop, задачи, запущенные внутри кластера, выполнялись уже не так быстро. Но всё же иметь общую платформу было очень удобно. Стало понятно, что в итоге мы будем использовать Hadoop.
Тестирование Hadoop показало, что Java нас не страшит, а по результатам личных бесед с разработчиками систем распределённых вычислений выяснилось, что скорость Hadoop не слишком отличается от реализаций, сделанных самостоятельно: что хорошо отлаженная реализация на языке C++ всего в полтора раза быстрее, чем Hadoop. Из этого стало понятно, что делать собственное решение нет смысла мы потратим значительно больше сил для того, чтобы его реализовать; поэтому Hadoop у нас прижился.
Единственное, что нас пугало то, что Hadoop был написан на Java. Программистов на С и C++ Java часто отталкивает довольно вальяжным отношением к ресурсам: среди них распространено мнение, что программа, написанная на Java, будет работать в 2, в 3, а то и в 10 раз медленнее, чем программа, написанная на языке С++. Это оказалось мифом: после того, как мы пересели на Hadoop, многие из наших программистов познакомились с Java, и выяснялось, что часто написать программу на Java можно быстрее, чем на С++, и работать она будет примерно с той же скоростью, что и ее аналог. Конечно же, в использовании Java достаточно нюансов, неприятных для программистов С++ (например, тот же самый сборщик мусора) но это уже следующий этап применения.
Ещё один вариант написать решение самостоятельно. Некоторые компании идут по такому пути: например, известно, что в Яндексе есть своя собственная реализация и MapReduce, и распределённой файловой системы. Мы проанализировали плюсы и минусы собственной реализации по сравнению с Hadoop. Использование самописного решения было бы оправдано, если бы мы нашли примеры того, что Hadoop работает медленнее или требует больше ресурсов, чем реализация, сделанная самостоятельно.
В качестве альтернативы мы рассматривали несколько вариантов. Одним из них была система Sector/Sphere. К сожалению, тесты в других отделах нашей компании показывали, что система на тот момент была довольно сырой, и мы не могли уверенно на нее положиться.
После обдумывания чужих архитектур стало понятно, что необходима платформа для распределённого выполнения задач. Мы остановились на Hadoop системе, которая позволяет распараллелить вычисления на большом кластере машин. У этого решения достаточно примеров успешного использования в крупнейших компаниях, таких, как Facebook и Yahoo! а значит, мы могли быть уверены, что Hadoop справляется с большими объёмами данных.
Готовое решение или собственная реализация?
Задачи, которые обрабатывали данные, такие как антиспам или ссылочный граф, вынуждены были работать отдельно, создавая еще большую путаницу. Мы понимали, что нужно что-то менять.
До весны 2012 года у нас вместо такой базы существовали две базы данных разного уровня со стороны спайдера, который имел свою собственную базу URL-ов, и со стороны индексатора. Это было крайне неудобно: допустим, если пользователь жаловался, что его сайт не индексируется, то для того, чтобы найти причину, при старой архитектуре пришлось бы анализировать массу данных. На это требовалось день-два, иногда даже неделя.
В мы рассмотрели примеры архитектуры поисковиков. Везде ключевую роль играет база данных, над которой удобно производить некоторые операции, исследовать и анализировать содержащиеся в ней документы.
Шаг за шагом, или Как мы строили свой поиск
Шаг за шагом, или Как мы строили свой поиск / Блог компании Mail.Ru Group / Хабрахабр
