Ошибаешься по всем пунктам...> только эта база явно не для хранения копий интернета (им совершенно не нужна суперотказоустойчивость, потеряется - скачает заново, )
По таким базам строят поисковые индексы и если из БД что-то пропадает, то однажды в индекс может не попасть какой-то топовый сайт. Поисковикам подобные фейлы наносят большой репутационный ущерб. Ну и "гарантии" СУБД существенно влияют на частотность обновления индексов.
> ... sql тут не нужен совсем ...
Для работы с СУБД всё равно нужен какой-то язык и SQL в качестве одного из ~ вполне подходит. Это в принципе ни к чему не обязывает, в частности под подмножеством SQL и кастомными расширениями можно спрятать даже совсем нереляционные СУБД и так делают везде.
> И не для информации о рекламных кликах - там слишком много insert/s, а тут явно сказано что они не для этого.
Как раз сказано обратное, т.е. СУБД отдельно поддерживает большие очереди. Вообше эта СУБД имеет большой throughput по записи хотя бы из-за распределённости.
> Какие-то детали поисковой системы могут, конечно, но как в них искать-то, полнотекстового поиска в этой штуке не заявлено, значит он у байды отдельно в чем-то другом живет.
Ты что, совсем тугой? Если бы было можно взять СУБД и сделать на основе FTS поиск по вебу, то сейчас имели бы дохерища поисковиков, но этого нет. Построение поискового индекса это довольно сложный, алгоритмоёмкий и многостадийный процесс...
> да и обращений к этим копиям крайне мало.
... и трогают все страницы в базе. Какие-то чаще, какие-то реже - всё зависит от популярности ресурса и вычислительных возможностей.
> так что скорее всего, что-то совсем другое. Например, данные user accounts ...
И другое наверняка тоже, поддерживать несколько СУБД для разных целей накладно.
