o7412369815963Может неверно выразилсяzheromoвсмысле?
A Availability - все клиенты могут одновременно читать и писать.
разернуто можно почитать например тут http://softwaremaniacs.org/blog/2010/01/31/brewers-cap-theorem/
o7412369815963Может неверно выразилсяzheromoвсмысле?
A Availability - все клиенты могут одновременно читать и писать.
zheromoимхо, монга может работать в любом режиме (AP,CP,AC)
У Couch мы имеем AP, у Mongo - CP.
dimabestЕсли двумя:
zheromo понесло :)
Столько слов… а как сделать выборку по двум диапазонам - я так и не увидел. Необязательно одним запросом - можно хоть двумя десятками.
LexanderПолностью согласен. Профилирование (основываюсь на профилировании собственных веб приложений) обычно показывает что процентов 80-90 времени исполнения приложение делает запросы к базе.zheromoМой собственный опыт оптимизации больших систем полностью подтверждается опытом действительно больших систем: http://www.insight-it.ru/highload, по сравнению с которыми мои работы - это просто муравьи на подоконнике. В двух словах, основные архитектурные проблемы (не путать с проблемами чисто аппаратными, например, disk IO) кроются в запросах к БД. Поэтому использование медленных интерфейсов к БД - табу для высоконагруженных систем.
Можно подробнее в чем это выражается.
LexanderМожно подробнее что подразумевается под медленным интерфейсом.zheromo… которые тоже используют тот же “медленный” интерфейс доступа к данным.
По поводу больших баз в данном случае мы имеем такие прелести как распределенность, инкрементную двунаправленную репликацию и т.д.
Ну вот скажите, зачем городить между двумя базами промежуточный слой в виде вэб-сервера для обслуживания REST API? А ведь его не выкинешь, он вшит в СУБД!
LexanderА в чем собственно недостаток? Если фича понадобилась - используем ее. Если нет - пользуемся как обычно.zheromoЯ не к тому, что у Couch плохая модель безопасности. Нет, я имею ввиду то, что наличие встроенного в Couch DB вэб-сервера (а также встроенный механизм обслуживания пиковых нагрузок) легко позволяет ей быть открытой для доступа извне. Но круг задач, которые требуют именно такой реализации доступа очень мал.
Couch по умолчанию слушает только localhost. Поэтому извне, даже из локальной сети на него не попадешь.
Таким образом, такие полезные фичи Couch DB являются одновременно недостатками.
zheromoHTTP. Сравните скорость текстового протокола HTTP и бинарного MySQL. Вот поэтому сервер серверу рознь.
Можно подробнее что подразумевается под медленным интерфейсом.
HTTP используется в качестве транспортного протокола (который кстати очень неплох), соответсвенно если бы использоваля какой-нибудь другой протокол, назовем его Х-протоколом, то для его реализации использовался бы Х-сервер.
Тот же mysql то же отдает данные на порту 3306 по своему протоколу и явно tcp-сервер который он использует тоже не получится выкинуть.
zheromoУгу. Прямой доступ к БД с моими затратами? Спасибочки. ;)
Как пример подхода - http://www.ajatus.info/
zheromoЕсли просто сложить результаты запросов - получим “ИЛИ”, то есть или диски по цене 30-150, или объемом 250-1000 :)
Если двумя:
view(view_name, startkey=sk1, endkey=ek1) + view(view_name, startkey=sk2, endkey=ek2)
как то так smile
dimabestApache CouchDb имеет полную интеграцию с Apache Lucene на уровне api вызовов.zheromoЕсли просто сложить результаты запросов - получим “ИЛИ”, то есть или диски по цене 30-150, или объемом 250-1000 :)
Если двумя:
view(view_name, startkey=sk1, endkey=ek1) + view(view_name, startkey=sk2, endkey=ek2)
как то так smile
Чтобы получить правильное “И” - нужно писать ручками код, который в цикле пробежит по каждой выборке и отфильтрует ненужное. Если диапазон широкий - прочитаем половину документов в RAM, а если широких диапазонов 2.. 3.. прочитаем в RAM больше чем лежит на диске :) Про производительность можно забыть.
Расскажите какое приложение (сложнее блога) можно написать с таким хранилищем? Самому интересно.
http://localhost:5984/dbname/_fti/design_doc/view_name?q=field_name:value
http://localhost:5984/dbname/_fti/design_doc/view_name?q=field_name:value&sort=other_field
http://localhost:5984/dbname/_fti/design_doc/view_name?debug=true&sort=billing_size&q=body:document AND customer:[A TO C]