В RSS-ленте проскочила новость о блог-посте под названием “Massive CouchDB Brain Dump”, который представляет из себя что-то вроде сборника фактов (предположений) о базе данных CouchDB.
Это не реляционная, и не объектная БД. Ее называют документо-ориентированной. Хотя обозвать сопоставление одному ключу серии пар имя-значение документом… Что тогда говорить об объектных СУБД? Они, наверное, мега-документо-ориентированные :)
С внешним миром общается черед HTTP, результаты выдает в виде JSON. При этом утверждается, что она очень быстрая. (Опять же у меня некоторое непонимание: HTTP и быстрое разве могут употребляться вместе? Но, видимо, здесь имеется в виду, что CouchDB не тратит время на join-ы, которые вынуждена выполнять РСУБД).
Используется lock-free design. Типа читатели не ждут писателей и других читателей. Неужели там есть версионность данных?
Утверждается, что CouchDB очень и очень здорово масштабируется. Типа, на ранних тестах было показано, что БД может обслуживать 20000 конкурентных подключений. И такой легкий выпад в сторону C++: мол, по словам главного разработчика, на традиционной многопоточной модели в C++ вряд ли удалось справиться с 500. Тут чувствуется какой-то маркетинговый bullshit. 20K параллельных соединений на одной машине выдержать можно, AFAIK, только при использовании очень эффективных I/O демультиплексоров (см. The C10K problem). И ни о какой модели “одно соединение – одна нить” здесь не может идти речи в принципе, а создать в C++ приложении 20K агентов, которые будут дергаться демультиплексором – как нефиг делать.
Говорится, что CouchDB сейчас набирает популярность, внимание к ней растет. Есть куча интерфесов к ней из разных языков программирования (собственно, что в этом странного – общение-то тупо через HTTP идет и результат в JSON приходит).
В общем, хороший образчик рекламы программного продукта (на мой взгляд). Нужно будет принять на вооружение ;)
Секрет в фразе "CouchDB is written in Erlang"
ОтветитьУдалитьТо бишь вопрос о параметрах CouchDB сводится к:
Erlang vs C++
У самого же CouchDB конкурентом можно назвать -
Oracle Berkeley DB XML.
Да, а насчет обработки одновременных подключений, то например:
ОтветитьУдалитьall the servlet containers did well up to about 4000 connections
Tomcat Scales to 16,000 Concurrent Connections
Так что в статье наверное перепутаны:
удобство написания ПО для обработки 20000 потоков, которое само "масштабируется", и обработка одновременных подключений.
Нет, вопрос Erlang vs C++ не ставится :) Как и вопрос Erlang vs любой статически типизированный язык. Поскольку динамическая типизация хороша в малых дозах, но большой проект на динамически-типизированном языке я бы делать поостерегся.
ОтветитьУдалитьBerkeley DB вряд ли конкурент, т.к. раньше он был платным. А CouchDB бесплатен. BDB старый продукт, а CouchDB еще, как я понимаю, в стадии активной разработки. Хотя надежность BDB, по личным впечатлениям, никакая (на примере BDB хранилищ в SVN).
А статье написали, что первые тесты показали, что CouchDB без проблем обрабатывает 20000 конкурентных подключений. На мой взгляд, здесь они имели в виду и то, и другое сразу. Т.е. Erlang позволяет писать так, чтобы одному соединению ставить в соответствие один процесс и не думать о масштабировании (в C++ с моделю нить-на-коннект это не пройдет). И, кроме того, в CouchDB задействован эффективный I/O демультиплексор, который позволяет держать по 20K одновременных соединений.
Berkeley DB вряд ли конкурент, т.к. раньше он был платным
ОтветитьУдалитьТак то раньше, а сейчас бесплатный. Не вникал правда в тонкости лицензирования.
И, кроме того, в CouchDB задействован эффективный I/O демультиплексор
Тут я не понимаю. Все равно после железа соединение обрабатывает - "драйвер" (в кавычках, потому что может быть частью монолитного ядра), ОСь, а уж потом нечто (твой код работающий с API ОСи, JVM, VM Erlang'а, ..., ). Если затык ниже твоего кода, или платформы, то как можно...
Не шарю вобщем в системных вопросах, но сомнения в 20000 - есть. Это если на спец.версии серверной ОСи какой, да железе, мне так думается, когда встречаю подобную инфу.
Не шарю вобщем в системных вопросах, но сомнения в 20000 - есть.
ОтветитьУдалитьUnix-система, если ее подтюнить (в этом шарят спецы по Unix-у), будет держать 20K соединений. Это наверняка. Проблема возникает в приложении, которое собирается определять, какие из этих 20K соединений готовы для чтения, какие для записи. Если делать это в тупую на сокетах, то придется делать, как минимум, 20 нитей, каждая из которых будет передавать по 1K дискрипторов в select. А после возврата из select-а будет в цикле искать готовые дискрипторы. Что очень долго.
Более продвинутые схемы работы, основанные на разных poll-ах или асинхронных сигналах, если они правильно сделаны, способны эту проблему значительно снизить.
Но дело в том, что самому эффективную схему работы с 20K дискрипторов писать -- очень сложно и неблагодарно. Поэтому все упирается в то, насколько эффективна чья-то 3rd party реализация (скажем, Boost.Asio или ACE_Reactor/ACE_Proactor).
Как известно, почти любой телекомовский софт содержит глючную, медленную реализацию Erlang OTP на C++ :)
ОтветитьУдалитьРазрабатывал когда-то SIP-router (B2BUA) со сложной логикой. Ядро было однопоточным (можно было запустить несколько ядер по количеству CPU), которое просто тупо крутилось в цикле, выполняя задачи одну за другой. Суть заключалась в том, что все задачи, выполняемые в ядре, должны были быть неблокирующими - за счет этого достигалась высокая скорость обработки. Ни одна задача не ждала другую. Контролировалось это, само собой, вручную. Демультиплексор для сетевых соединений - epoll на Linux, kqueue - на FreeBSD и т.д. Собственная реализация. Работало довольно шустро и обрабатывало сетевые запросы в режиме очень высокой параллельности.
Через некоторое время после этого узнал об Erlang и, изучив подробнее, был поражен сходством конструктивных решений. Вот только в Erlang такая параллельность - бесплатна с т.з. написания кода. Пишешь в обычном (блокирующем) стиле, а система сама занимается всей асинхронщиной. После этого писал сервера и на том и на другом и, в частности, доморощенный IMAP сервер в двух вариантах - на Erlang и на C++ с использованием вышеописанных схем. Фактический вывод был таков - сервер, написанный на Erlang с применением тупой схемы "процесс на соединение", обладает очень низкой latency. Добиться такой же latency на C++ возможно, но ценой значительно больших усилий. Время же обработки отдельного запроса на Erlang выходило, как правило больше - за счет издержек работы со строками. Т.е. с точки быстродействия Erlang-у, конечно, далеко до C++, но параллелизм там - практически идеален.
2CrystaX: ну так именно в этом и суть. Erlang дает разработчику готовую платформу в которой многие вещи уже сделаны и сделаны очень качественно. Но, с другой стороны, там динамическая типизацияю с ее скоростью и сопровождаемостью.
ОтветитьУдалитьИмхо, было бы интереснее сравнивать с Erlang-ом платформу с похожими возможностями, но для статически-типизированного языка. Не суть C++ это будет, или C#/Java/Scala/D/OCaml.