Новые впечатления от CouchDB
Oct. 17th, 2015 02:14 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ermouthЯ три недели провозился с CouchDB – писáл одну интересную для меня фичу. В результате фичу я реализовал, но до pull request‘а так и не довёл, плюнул.
Любопытно, что саму фичу и свои тесты к ней я написал за 4 дня, из которых два дня читал книжки по Erlang-у. Получил peer review, что сделал, в общем, не позор – и это радует. А вот большинство остальных впечатлений – не очень.
Codebase
Я никогда не видел такого codebase-а. Код размазан более, чем по 30(!) репозиториям – без всякого, на мой взгляд смысла. Комментариев в коде нет от слова совсем. Все инструкции по сборке или неполны, или просто неверны. Без косяков проект собирается только со вполне определённым набором ключей – которые надо ой как поискать. Но это всё цветочки.
Тесты
Ягодки – тесты. Это просто адище, какое-то нереальное. Даже получив от одного из контрибуторов коротенькое up to date описание, что к чему, я не смог заставить их толком работать – причём даже те, что работать, по идее, должны бы. Там нереальный какой-то зоопарк, наслоения из кода на Эрланге, JS и – тарам-папам – Ruby. Ну и скрипты конечно всех мастей. И конечно, никаких актуальных описаний нет в помине, а те, что всё же удаётся найти, оказываются устаревшим или просто неверными.
Интересно, что заставить работать некоторые тесты не могут даже тамошние фюреры – недавно был проанонсирован на комьюнити запрос о помощи. Феерия, в общем. Это всё, конечо, можно побороть – но я просто плюнул, выкинув из жизни две недели перед этим. Это абсолютно ненормальная ситуация, когда тесты требуют времени просто чтобы их запустить, на порядок большего, чем написать функционал, который тесты должны тестировать. Впрочем, энтузиастов это, видимо устраивает.
Кластер
Любопытно, что сейчас из CouchDB делается кластер – в проект мёржится код, который работает в Айбиэм Клодант. Допускаю, что в этом есть смысл – но почитав кое-какие обсуждения особенностей реализации кластера, я пока как минимум поостерегусь таким кластером пользоваться. Просто есть с чем сравнивать, и сравнение пока, скажем так, не очень (даже, скорее очень не) в пользу. Скажем, то, как чуваки реализуют sloppy quorum, в моей картине мира не лезет просто ни в какие ворота – правда, я и не эксперт ни разу.
Ну и плюс обязательный overhead на http-стэк в каждом запросе смотрится более-менее оправданным в single-node режиме, но выглядит совершенно бессмысленной тратой ресурсов в крупном проекте. А кластер – это всё же обычно крупные проекты.
Javascript
Главная сила CouchDB – возможность использования javascript для формирования индексов, map/reduce запросов и других плюшек. Это, в совокупности в веб-интерфесом, здорово снижает порог вхождения. Но в этой силе кроется и главная слабость.
Реализация всех этих дел, скажем так, далека от производительной. Это, в общем, известный факт – но мне надо было самостоятельно перешерстить все детали, чтобы понять, что при имеющемся подходе там достигнут потолок и быстрее оно не станет, какие бы усилия не прикладывались.
Сама CouchDB написана на Эрланге, и, соответсвенно, при передаче данных в процесс Spidermonkey (дада, версии 2011 года) мы имеем все прелести, с этим связанные. Передача данных из Эрланга в Spidermonkey идёт через stdio stream, что, очевидно, предполагает сериализацию данных запроса в Erlang-части, потом десериализацию в Spidermonkey, потом снова сериализацию, уже ответа, и снова разбор. А потом снова сериализация, уже для отправки ответа по http. Это очень дорого.
Плюс ко всему, на один пулл функций в бакете там один процесс Spidermonkey – а так как javascript однопоточен по определнию, это сразу влечёт за собой весьма тяжёлые последствия в плане доступного паралеллизма обработки. Нет его там, и взяться ему неоткуда. Это существенно нивелируется кэшированием индексов, но не всё на этом свете – индексы, и не всё можно закэшировать.
К счастью, CouchDB поддерживает написание индексов и других JS-related штук не только на JS, но и на нативном Эрланге, что совершенно, в целом, снимает все вышеуказанные проблемы. Но много ли людей, особенно из JS-комьюнити, пишут на Эрланге? Да и не очень-то это безопасно, потому что Эрланг-то не в песочнице живёт.
Итого
В целом, моё трёхнедельное приключение было вполне себе полезным. Я теперь точно знаю, чего можно, а чего нельзя добиться от CouchDB, как устроено тамошнее комьюнити (не сунусь туда больше сам и никому не посоветую) и каков у CouchDB оптимальный профиль применения.
Если коротко:
В общем, CouchDB мы как использовали, так и будем использовать – но на версию 2.0 я не буду переходить точно.
Любопытно, что саму фичу и свои тесты к ней я написал за 4 дня, из которых два дня читал книжки по Erlang-у. Получил peer review, что сделал, в общем, не позор – и это радует. А вот большинство остальных впечатлений – не очень.
Codebase
Я никогда не видел такого codebase-а. Код размазан более, чем по 30(!) репозиториям – без всякого, на мой взгляд смысла. Комментариев в коде нет от слова совсем. Все инструкции по сборке или неполны, или просто неверны. Без косяков проект собирается только со вполне определённым набором ключей – которые надо ой как поискать. Но это всё цветочки.
Тесты
Ягодки – тесты. Это просто адище, какое-то нереальное. Даже получив от одного из контрибуторов коротенькое up to date описание, что к чему, я не смог заставить их толком работать – причём даже те, что работать, по идее, должны бы. Там нереальный какой-то зоопарк, наслоения из кода на Эрланге, JS и – тарам-папам – Ruby. Ну и скрипты конечно всех мастей. И конечно, никаких актуальных описаний нет в помине, а те, что всё же удаётся найти, оказываются устаревшим или просто неверными.
Интересно, что заставить работать некоторые тесты не могут даже тамошние фюреры – недавно был проанонсирован на комьюнити запрос о помощи. Феерия, в общем. Это всё, конечо, можно побороть – но я просто плюнул, выкинув из жизни две недели перед этим. Это абсолютно ненормальная ситуация, когда тесты требуют времени просто чтобы их запустить, на порядок большего, чем написать функционал, который тесты должны тестировать. Впрочем, энтузиастов это, видимо устраивает.
Кластер
Любопытно, что сейчас из CouchDB делается кластер – в проект мёржится код, который работает в Айбиэм Клодант. Допускаю, что в этом есть смысл – но почитав кое-какие обсуждения особенностей реализации кластера, я пока как минимум поостерегусь таким кластером пользоваться. Просто есть с чем сравнивать, и сравнение пока, скажем так, не очень (даже, скорее очень не) в пользу. Скажем, то, как чуваки реализуют sloppy quorum, в моей картине мира не лезет просто ни в какие ворота – правда, я и не эксперт ни разу.
Ну и плюс обязательный overhead на http-стэк в каждом запросе смотрится более-менее оправданным в single-node режиме, но выглядит совершенно бессмысленной тратой ресурсов в крупном проекте. А кластер – это всё же обычно крупные проекты.
Javascript
Главная сила CouchDB – возможность использования javascript для формирования индексов, map/reduce запросов и других плюшек. Это, в совокупности в веб-интерфесом, здорово снижает порог вхождения. Но в этой силе кроется и главная слабость.
Реализация всех этих дел, скажем так, далека от производительной. Это, в общем, известный факт – но мне надо было самостоятельно перешерстить все детали, чтобы понять, что при имеющемся подходе там достигнут потолок и быстрее оно не станет, какие бы усилия не прикладывались.
Сама CouchDB написана на Эрланге, и, соответсвенно, при передаче данных в процесс Spidermonkey (дада, версии 2011 года) мы имеем все прелести, с этим связанные. Передача данных из Эрланга в Spidermonkey идёт через stdio stream, что, очевидно, предполагает сериализацию данных запроса в Erlang-части, потом десериализацию в Spidermonkey, потом снова сериализацию, уже ответа, и снова разбор. А потом снова сериализация, уже для отправки ответа по http. Это очень дорого.
Плюс ко всему, на один пулл функций в бакете там один процесс Spidermonkey – а так как javascript однопоточен по определнию, это сразу влечёт за собой весьма тяжёлые последствия в плане доступного паралеллизма обработки. Нет его там, и взяться ему неоткуда. Это существенно нивелируется кэшированием индексов, но не всё на этом свете – индексы, и не всё можно закэшировать.
К счастью, CouchDB поддерживает написание индексов и других JS-related штук не только на JS, но и на нативном Эрланге, что совершенно, в целом, снимает все вышеуказанные проблемы. Но много ли людей, особенно из JS-комьюнити, пишут на Эрланге? Да и не очень-то это безопасно, потому что Эрланг-то не в песочнице живёт.
Итого
В целом, моё трёхнедельное приключение было вполне себе полезным. Я теперь точно знаю, чего можно, а чего нельзя добиться от CouchDB, как устроено тамошнее комьюнити (не сунусь туда больше сам и никому не посоветую) и каков у CouchDB оптимальный профиль применения.
Если коротко:
- если map/reduce функции и всякие другие штуки написаны на JS, лимит авторизованных и активно пишуших/читающих пользователей в самом лучшем случае – сотни;
- репликация действительно очень хороша, как минимум для однонодовых инстансов – но только до тех пор, пока она не идёт через фильтр-функцию на JS;
- кластер из CouchDB – это ерунда, если нужен нормальный кластер со схожим функционалом – есть couchbase.
В общем, CouchDB мы как использовали, так и будем использовать – но на версию 2.0 я не буду переходить точно.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-10-17 06:55 pm (UTC)Я это всё проходил, когда пилил эрливидео: 12 пакетов с раздельными либами.
Сейчас я обсуждаю с коллегами вклейку _всех_ зависимостей в основной гит. Когда делаешь продукт, надо думать о продукте в целом.
Тесты у нас тоже: я очень требую, что бы всё работало на разных компьютерах. Из 1000 тестов мигающих разве что 10 штук.
no subject
Date: 2015-10-17 09:19 pm (UTC)Есть прекрасный форк CouchDB – BarrelDB – в котором это сделано. Не прямо уж всех – сторонние либы всё же снаружи – но модуляризации самого продукта до уровня крошева нет.
Добро пожаловать в друзья. Когда-то смотрел ваше выступление по erlyvideo, хорошее.
no subject
Date: 2015-10-21 10:30 am (UTC)Я ума не приложу, как можно мейнтейнить проект, если не форкать все зависимости в основной репозиторий. Ну можно, но это будет прототип или университетская поделка, не production.
В принципе, если твой пост не поэтическое преувеличение, а правда, то по таким симптомам CouchDB нельзя использовать как long-term dependency, потому что понятно, что он умрёт.
no subject
Date: 2015-10-21 11:02 am (UTC)Это выглядит просто как в анекдоте https://otvet.mail.ru/question/54612510 ))
> CouchDB нельзя использовать как long-term dependency, потому что понятно, что он умрёт
А вот это мы ещё посмотрим, у меня есть план )