Здравствуйте, borisman3, Вы писали:
B>http://paskoboris.blogspot.com/2011/03/scalable-orm.html
Насчёт некластеризуемости современных СУБД заявление довольно-таки смелое.
Посмотрите на описания решений tpc-c на tpc.org, узнаете много нового.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, borisman3, Вы писали:
B>>http://paskoboris.blogspot.com/2011/03/scalable-orm.html S>Насчёт некластеризуемости современных СУБД заявление довольно-таки смелое. S>Посмотрите на описания решений tpc-c на tpc.org, узнаете много нового.
Теперь посчитаем (я могу здорово ошибиться в рассчетах, поправьте меня если не трудно):
30000 в минуту = 500 транзакций в секунду. Предположим каждый пользователь делает одну транзакцию в 10 секунд. В реальных кластерных системах это число может быть значительно выше (до нескольких транзакций в секунду для MMO игр например).
Получается, мой кластер может поддержать работу 5000 человек. Мягко говоря, не впечатляет.
Положим, решение сделанное мной полгода назад способно держать 8-10К одновременных пользователей с одной ноды кластера. Всего нод 3. И как собственно мне в мое решение встроить оракловый кластер ??? Арифметика как-то не сходится у меня...
Здравствуйте, Sinclair, Вы писали:
B>>http://paskoboris.blogspot.com/2011/03/scalable-orm.html S>Насчёт некластеризуемости современных СУБД заявление довольно-таки смелое. S>Посмотрите на описания решений tpc-c на tpc.org, узнаете много нового.
Собственно, не узнаем. РСУБД освоили только часть треугольника CAP.
Каждый раз, когда кто-то берется рассуждать об "noSQL вообще", без детализации хотя бы до класса (document-oriented, key-value, column-oriented), рука сама тянется к револьверу.
Из-за чрезвычайной гибкости навигационные базы в принципе не могут иметь языка запросов 4-го поколения.
Что такое язык 4-го поколения?
Берем в руки Neo4J или OrientDB (graph-базы данных, то есть NoSQL), подключаем к ним Gremlin и вуаля:
// calculate the primary eigenvector (eigenvector centrality) of a graph:
g = new Neo4jGraph('/tmp/neo4j')
m = [:]; c = 0;
g.V.outE.inV.groupCount(m).loop(3){c++ < 1000}
m.sort{a,b -> a.value <=> b.value}
v.outE{it.label=='knows'}.inV{it.age > 21 & it.name.matches('jo.{2}|JO.{2}')}.age
Не говоря уже о том, что OrientDB и [название забыл ] поддерживают подмножество SQL.
Для понятности приведу пример. Допустим у Вас есть некий объект "Игрок" у которого имеется набор "Предмет" ов и у каждого предмета есть поле "количество применений". Предположим, вам надо найти определенный предмет и уменьшить его количество применений, причем если оно достигло нуля, предмет следует убрать из инвентаря игрока. Понятное дело, все это должно случиться атомарно, т.е. в рамках одной транзакции.
Как описать подобную транзакцию при отсутвии языка запросов 3-го поколения ? Никак.
Как подобные транзакции реализуются в noSQL ? Посредством get/put API c CAS семантикой.
Можно попдробнее? Как это реализуется в РСУБД и языках 4-го поколения?
Здравствуйте, borisman3, Вы писали:
B>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, borisman3, Вы писали:
B>>>http://paskoboris.blogspot.com/2011/03/scalable-orm.html S>>Насчёт некластеризуемости современных СУБД заявление довольно-таки смелое. S>>Посмотрите на описания решений tpc-c на tpc.org, узнаете много нового.
B>Смотрим: B>http://tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all&amp;version=5%&currencyID=0
B>Получается грубо за 30 000 баксов можно поиметь кластер, "прокачивающий" грубо 30000 транзакций в минуту (http://tpc.org/tpcc/results/tpcc_result_detail.asp?id=110120201).
Не совсем. Приведённый результат: за 30М баксов можно получить кластер, прокачивающий 30M транзакций в минуту. Или 500K транзакций в секунду.
B>30000 в минуту = 500 транзакций в секунду. Предположим каждый пользователь делает одну транзакцию в 10 секунд. В реальных кластерных системах это число может быть значительно выше (до нескольких транзакций в секунду для MMO игр например).
На всякий случай напомню, что tpc-c под "транзакцией" понимает "проведение заказа". Детали приведены в отчёте. Что понимается под "транзакцией" в ММОRPG?
B>Получается, мой кластер может поддержать работу 5000 человек. Мягко говоря, не впечатляет.
И, да, таки 5М человек. Мягко говоря, впечатляет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, borisman3, Вы писали:
B>Положим, решение сделанное мной полгода назад способно держать 8-10К одновременных пользователей с одной ноды кластера. Всего нод 3. И как собственно мне в мое решение встроить оракловый кластер ??? Арифметика как-то не сходится у меня...
Да, давайте посмотрим на арифметику с другого конца. Ваше решение держит примерно 30k пользователей. Предположим, речь идёт об 1 транзакции в секунду, т.е. нужно получить 1800000 tpm. Пожалуйста — http://tpc.org/tpcc/results/tpcc_result_detail.asp?id=110083001. Имеем требуемую производительность на одной ноде. Если вас смущает стоимость решения, то напомню, что речь идёт об 1ТБ памяти и 70ТБ дискового пространства.
Если ваша база данных поскромнее размером, то пропорционально скромнее будет и стоимость решения — без существенного снижения быстродействия транзакций.
Так что да, арифметика таки не сходится. Причём существенно не в вашу сторону.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>Можно попдробнее? Как это реализуется в РСУБД и языках 4-го поколения?
В РСУБД это реализуется посредством механизма явных транзакций:
BEGIN TRAN
Найти игрока
найти предмет
уменьшить поле "кол-во использований"
удалить предмет если необходимо
COMMIT
В распространненных noSQL (memcached, membase, REDIS, mongodb) очень трудно (скорее невозможно) эффективно реализовать транзакции с достаточно finer-grained locking'ом потому что данные никак не интерпертируются в отличие от РСУБД, где структура данных известна базе.
M>>Можно попдробнее? Как это реализуется в РСУБД и языках 4-го поколения? B>В РСУБД это реализуется посредством механизма явных транзакций:
B>BEGIN TRAN B> Найти игрока B> найти предмет B> уменьшить поле "кол-во использований" B> удалить предмет если необходимо B>COMMIT
B>В распространненных noSQL (memcached, membase, REDIS, mongodb) очень трудно (скорее невозможно) эффективно реализовать транзакции с достаточно finer-grained locking'ом потому что данные никак не интерпертируются в отличие от РСУБД, где структура данных известна базе.
Да ладно, все это решаемо. Выделенное выше точно так же делается с помощью механизма явных транзакций. В том же Redis'е — это MULTI и EXEC, http://redis.io/topics/transactions
ТО есть это не имеет никакого отношения ни к языку запросов ни к NoSQL'ности. Начинаем транзакцию, делаем «get/set», заканчиваем транзакцию. Подход ничем не отличается ни в RDBMS ни в NoSQL.
Возвращаемся к контексту:
Из-за чрезвычайной гибкости навигационные базы в принципе не могут иметь языка запросов 4-го поколения.
Что такое язык 4-го поколения? И почему навигационные базы данных (что бы это ни значило) не могут их иметь?
Здравствуйте, borisman3, Вы писали:
B>В распространненных noSQL (memcached, membase, REDIS, mongodb) очень трудно (скорее невозможно) эффективно реализовать транзакции с достаточно finer-grained locking'ом потому что данные никак не интерпертируются в отличие от РСУБД, где структура данных известна базе.
Можно с помощью "tension pattern" ( http://stackoverflow.com/questions/299723/can-i-do-transactions-and-locks-in-couchdb ).
Но да, в этом случае получаем типичные проблемы РСУБД.
S>Да, давайте посмотрим на арифметику с другого конца. Ваше решение держит примерно 30k пользователей. Предположим, речь идёт об 1 транзакции в секунду, т.е. нужно получить 1800000 tpm. Пожалуйста — http://tpc.org/tpcc/results/tpcc_result_detail.asp?id=110083001. Имеем требуемую производительность на одной ноде. Если вас смущает стоимость решения, то напомню, что речь идёт об 1ТБ памяти и 70ТБ дискового пространства.
Да, цена в 800К баксов за 30К работающих пользователей — это конечно перебор. Т.е. каждый пользователь мне обходится в 26 баксов. Это очень дорого, особенно если Вы — такие гиганты как Facebook или (не такие гиганты, но все же) — yellow-pages.ca.
Вообще существует upper bound (причем не такой уж большой) на количество транзакций которые может пропустить через себя реляционная система. Например, базируясь исключительно на наших с Вами примерах, можно сказать что 30К пользовтелей — это предел, потому что мало кто захочет платить 26 баксов за пользователя, а уж тем более — больше 26 баксов за пользователя.
Вообще мне кажется у нас просто немного разные задачи и цифры, которые впечатляют Вас для меня являются совершенно неутешительными.
IT>Концовка невнятна. Непонятно, что же хотел сказать автор?
Автор хотел внести идею об xBASE системах, в которых язык приложения был тесно завязан на базу данных. И предложил рассматривать приложения на как клиент-сервер, а как сервер-кластер.
Здравствуйте, Miroff, Вы писали:
M>Каждый раз, когда кто-то берется рассуждать об "noSQL вообще", без детализации хотя бы до класса (document-oriented, key-value, column-oriented), рука сама тянется к револьверу.
В моем случае большой разницы нет. Я же показываю что document-oriented noSQL на практике чаще всего вырождаются в key-value за счет того что невозможно формулировать сложные транзакции к документам.
M>Да ладно, все это решаемо. Выделенное выше точно так же делается с помощью механизма явных транзакций. В том же Redis'е — это MULTI и EXEC, http://redis.io/topics/transactions
Признаю свою ошибку.
M>Возвращаемся к контексту:
M>Что такое язык 4-го поколения? И почему навигационные базы данных (что бы это ни значило) не могут их иметь?
float sum = 0;
for (Record r : allRecords) {
sum += r.money;
}
Причина по которой навигационные базы не имеют языка запросов 4го поколения в том что стурктура базы очень гибкая и движок не может сделать каки-либо предположения о структуре. Допускаю что это неуниверсальное утверждение и что в принципе (потеряв гибкость конечно) можно сделать навигационную базу данных с какой-то более жесткой структурой, но тогда это уже будет не совсем навигационная база данных.
справедливости ради стоит заметить что REDIS вообще стоило бы исключить из рассмотрения так как (надеюсь что лишь "пока что") REDIS толком не кластеризуется (поддерживается только mate-slave репликация), а значит и не очнеь масштабируется.
Здравствуйте, Cyberax, Вы писали:
B>>В распространненных noSQL (memcached, membase, REDIS, mongodb) очень трудно (скорее невозможно) эффективно реализовать транзакции с достаточно finer-grained locking'ом потому что данные никак не интерпертируются в отличие от РСУБД, где структура данных известна базе. C>Можно с помощью "tension pattern" ( http://stackoverflow.com/questions/299723/can-i-do-transactions-and-locks-in-couchdb ).
Все верно, это как раз тот самый механизм Compare-And-Swap, он же Test-And-Set, он же transactional memory transaction restart, он же Collision Detection (в Ethernet сетях).
Сам по себе этот механизм неплох — это собственно базовый механизм lock-free programming, он очень даже подходит для сильно распределенных вычислений. У него есть конечно недостатки, но как general-purpose механизм он очень даже полезен.
C>Но да, в этом случае получаем типичные проблемы РСУБД.
Проблема состоит в том, что его применяют немного не так как я считаю нужным. Перезапускаемая транзакция (compare-and-set) происходит на стороне клиента, а не сервера. Это приносит целую кучу проблем (про которые я писал), но зато дает возможность серверу быть language-agnostic, т.е. использоваться клиентами, написанными на разных языках.
Если нам не помогут, то мы тоже никого не пощадим.
] поддерживают подмножество SQL.