Как стать автором
Поиск
Написать публикацию
Обновить

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

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров2.8K
Всего голосов 24: ↑24 и ↓0+34
Комментарии10

Комментарии 10

а в вк нормальные комментарии будут?

ОК - это Одноклассники что-ли? Там ещё кто-то что-то пишет? Удивительно

Там не просто пишут. Там ведут большую и серьёзную исследовательскую работу.

А может вы лучше займетесь модерацией комментариев? Ведь она у вас полностью отсутствует. Так мало того, нет системы, где можно разом посмотреть комментарии на всех постах, приходится тыкать на каждый, а при огромном количестве комментариев это превращается в ад. Или вы специально оставляете даже высказывания экстремистского характера, чтобы потом доложить, что «количество комментариев возросло на 11%»?

Плоско-древовидные (Например, YouTube, ВК)

Ужасный формат, если нет хронологического порядка вложенных комментариев. Он у вас есть, кстати? Понять ход дискусси невозможно. Хотя, для бесполезного срача подходит, чем комментарии в YT и ВК и являются.

Да, в нашем случае мы как раз решили сортировать комментарии внутри "поддискуссии" именно в хронологическом порядке, пытаясь найти хороший компромисс между полностью линейными комментариями, сортируемыми по дате написания, и древовидными.

По итогу нам в поддержку жалоб пользователей о том, что читать комментарии стало неудобно, не поступало, так что есть основания полагать, что у нас получилось неплохо)

почему ICQ и Агент закрыли, а ОК и Мой мир не закрывают никак? :)

Спасибо, есть несколько вопросов:

  1. Почему именно Cassandra, а не Сцилла? Которая по слухам более эффектна, при этом совместима

  2. Вы при запросе пользователя , на прямую забираете из БД (через толстый клиент но все же) или используете кэш перед ней?

  3. А пробовали тестировать другие БД? Тот же Тарантул для этой задачи? В целом по срокам вышло не долго, с новой было бы явно дольше, но все же.

Привет! Спасибо огромное за вопросы)

  1. К сожалению в те года, когда писались ОК, ScyllaDB ещё не было вообще. В те времена даже Cassandra была ещё только первой версии, по итогу мы с большим скрипом смогли перейти на вторую. При этом, конечно, базовой функциональности Кассандры нам давно не хватало. У нас в ней реализован толстый клиент, добавлена поддержка транзакций и ещё очень много всякого. Т.е нашу "Кассандру" даже "Кассандрой" назвать можно лишь со звёздочкой, ибо это скорее своя собственная БД, которая берет истоки из Кассандры. Поэтому про совместимость не просто со сцилой, но даже банально с Кассандрой более новых версий говорить прям совсем не приходится. Можно почитать немного подробнее тут: NewSQL = NoSQL+ACID / Хабр

  2. Да, мы используем кеширование, оно встроено в толстый клиент нашей Кассандры, т.е кеш лежит на самой ноде, и реализовано нами в рамках модернизаций, сделанных над обычной Кассандрой. Оно работает через off-heap память и использует get_or_set подход, т.е пытаемся достать из Кеша, если не получается, то идём в Кассандру, подгружая их в кеш для последующих запросов. В дополнение через PMS мы можем настроить желаемый объем кеша и прочие подобные параметры. Можно вот тут почитать подробнее: Как мы избавились от пауз GC с помощью собственного java off-heap storage решения / Хабр

  3. К сожалению у задачи действительно были довольно небольшие сроки, так что времени на эксперименты особо не было. Главной преимуществом решения с древовидным индексом на основе колоночного семейства стало то, что мы по-факту вообще никак не меняем нашу архитектуру, у нас остаются все те же сервера, все те же ноды. Единственное место, что мы меняем - это толстый клиент нашей Кассандры, запущенной на каждой ноде. Мы добавляем на него логику, которая локально ходит в колоночный - индекс, а затем из него идёт так же локально в колоночное семейство с комментариями дискуссиями. Все это происходит в рамках одной ноды Кассандры, т.е на одном сервере. Если бы мы добавляли новую базу данных - это либо надо было бы поднимать новые сервера и ходить на них по сети, что дороже по ресурсам и при этом по производительности тоже неприятно (ходить по сети явно сложнее, чем ходить локально). Либо же на каждой ноде Кассандры запускать свою собственную маленькую локальную базу данных, т.е чтобы у каждой ноды Кассандры была ещё одна база данных, которая другая и используется под индекс, что кажется тоже довольно затратным делом по нагрузке на ноду как на сервер и забивании её ресурсов. По этой причине мы сделали индекс на самой Кассандре, нас устроило производительность и решение вышло лёгким, поэтому дальше экспериментировать и не пришлось) В дополнение наш индекс, так как он работает на все той же нашей кассандре, тоже использует off-heap кеширование, а с учетом его размеров (крайне малых), для 99% дискуссий, которые находятся на ноде, он может без проблем быть полностью подгруженным в off-heap память, даже если выделить под кеш не так уж и много места, т.е в саму кассандру за индексом нам ходить почти вообще не прийдется.

    Надеюсь, что ответы на вопросы вышли полноценными!)

Спасибо за такой комент!:) Ответил полностью, теперь я осознал объем работы.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий