LINUX.ORG.RU

Вышел CouchDB 1.0

 , , ,


0

0

С песнями и плясками явился миру первый мажорный релиз Apache CouchDB, открытой и свободной документо-ориентированной системы управления базами данных, написанной на Erlang.

Релиз носит гордый номер 1.0.0, однако список изменений с предыдущей версии невелик и содержит в основном оптимизацию и багфиксы.

На момент написания новости ебилдов не обнаружено, в AUR и PPA также тишина.

Ознакомиться с кодом можно здесь.

Довольные собой разработчики собирают желающих отпраздновать событие.

>>> Страница загрузки (+ список изменений)



Проверено: catap ()
Последнее исправление: mutley (всего исправлений: 1)

Ответ на: комментарий от JFreeM

>> Вопрос по теме - у NoSQL есть мат. фундамент как у реляционных БД?

насколько я знаю, нету. Это чисто прикладная штука.

Смотря у каких noSQL. Например теория графов для так называемых сетевых БД. К слову частным, вырожденным и упращенным, случаем сетевой БД являются реляционные БД (ага, SQL) и ирархические БД (да любая современная FS).

anonymous
()
Ответ на: комментарий от libre

Ради интереса тестировал вставку данных на 150 гигабайтной базе. (Интерес возник, потому что есть проект где используется PotgreSQL для задачи с таким объемом данных). У CouchDB скорость была порядка 80 записей в секунду (у PostgreSQL не помню сколько но в разы меньше). Так что для определенных задач я думаю это очень даже полезный проект.

pi11 ★★★★★
()
Ответ на: комментарий от JFreeM

то есть, Вы считаете js - это хороший, годный язык для написания запросов к базе данных?

Для couchdb на js пишутся не запросы. Но не будем занудствовать, язык как язык, позволяет решать возложенные на него задачи. А вы считаете, что на эту роль подошел бы кто-то другой? Поделитесь, если не секрет?

baverman ★★★
()
Ответ на: комментарий от Attila

>Вопрос по теме - у NoSQL есть мат. фундамент как у реляционных БД?

да тот же самый. сейчас 99% БД используются в полу или вообще нереляционном режиме.

AVL2 ★★★★★
()
Ответ на: комментарий от pi11

У CouchDB скорость была порядка 80 записей в секунду (у PostgreSQL не помню сколько но в разы меньше)

Очень сомнительный тест. Это с bulk insert'ом и там и там?

baverman ★★★
()
Ответ на: комментарий от JFreeM

>то есть, Вы считаете js - это хороший, годный язык для написания запросов к базе данных?

не для запросов, а для формирования видов документов. Да, это один из сильных ходов авторов этой БД.

AVL2 ★★★★★
()

Меня маргинальщина пугает уже в силу своей маргинальщины. _Возможно_ НоСЫКУЛЬ найдёт своё место в вебе, но в обычные СУБДшные задачи я б с ним не лез. Ырланг вообще не обсуждается - стрём.

matumba ★★★★★
()
Ответ на: комментарий от pi11

Надо уточнить, что у меня паралелльно шла вставка (около 40 процессов я запускал). Собственно на реальном PotgreSQL проекте почти тоже самое.

pi11 ★★★★★
()
Ответ на: комментарий от holka

Мнезиа уже есть, ага.

На сколько я знаю, мнезией можно пользоваться только из эрланга. Поэтому пусть лежит и пылится рядышком с телекомами.

baverman ★★★
()
Ответ на: комментарий от pi11

около 40 процессов я запускал

Это было нагрузочное тестирование? Иначе зачем столько много? Или обладатель спарка?

baverman ★★★
()
Ответ на: комментарий от baverman

Потому что в реальной задачи (для которой я хотел использовать CouchDB, но потом я ее забросил) нужно было сохранять данные от многих источников (чем больше - тем лучше). На PostgreSQL процессы «висели» дожидались своей очереди - не обеспечивал он достаточной скорости при параллельной вставке данных.

pi11 ★★★★★
()
Ответ на: комментарий от pi11

так сабж без транзакций, поставьте их с постгресом в равные условия - вставляйте в постгресе с помошью COPY и получите больше 10k ins/s

ventilator ★★★
()
Ответ на: комментарий от ventilator

База состояла из одной таблички.

pi11 ★★★★★
()
Ответ на: комментарий от ventilator

Каждым процессом сохранять данные в файл (по одной записи), затем с помощью COPY загружать? Без ключей или за целостностью данных самому следить? В чем тогда профит РСУБД будет?

pi11 ★★★★★
()
Ответ на: комментарий от pi11

Ну, для начала надо определиться, хотим мы скорости или чтобы за целостностью данных за нас следили.

Zenom ★★★
()
Ответ на: комментарий от Zenom

Никто и не спорит, у каждого решения свои инструменты.

pi11 ★★★★★
()
Ответ на: комментарий от pi11

а вам данные только инсертить важно иль может еще селект из этой таблички тоже бывает? Сравните скорость выборки заодно. Ну и конечно при базе в одну табличку РСУБД не имеют никакого профита.

ventilator ★★★
()
Ответ на: комментарий от ventilator

Выбирать тоже нужно конечно, один раз - чтобы эти данные обработать и «положить» в другую табличку. Проверить не могу сейчас проект помер.

pi11 ★★★★★
()
Ответ на: комментарий от JFreeM

>не путайте пожалуйста железячную организацию данных и

софтварную. Там действуют различные принципы.

Неверно. То что контроллер умеет аппартно считать контрольные суммы, под управлением микрокода(прошивки), вовсе не делает RAID контроллер чисто железным решением. Неудачное сравнение вообще то.

Fastman
()
Ответ на: комментарий от ventilator

Получится, там был цикл - загружаем данные, после некоторого времени новые данные в первоначальную таблицу не поступают. Пишем в новую таблицу, а первоначальную таблицу обрабатываем и сохраняем в итоговую таблицу. И так далее таблица наполняется - сбрасываем данные.

pi11 ★★★★★
()
Ответ на: комментарий от Zenom

Ну так там заточка идет совсем на другое.

Там нет ни объединений, ни пересечений ни нормализации, а вместо селекта простой функциональный мап функции на таблицу, который возвращает нечто.

И служебных полей всего два - id да revision. Первое, чтобы обеспечить репликацию, а второе, чтобы разрулить конфликты при внесении изменений сразу двумя клиентами.

AVL2 ★★★★★
()
Ответ на: комментарий от libre

> Бесполезное говно без транзакций

Софтверные транзакции реализованы на уровне библиотек, то есть для тех кому что-то простенькое понадобиться может. Но зачем везде транзакции пихать? Не для этого оно.

pythonist
()
Ответ на: комментарий от JFreeM

> закопайте это УГ. noSQL бд не нужны.

Не обобщайте. Задачи разные бывают.

pythonist
()
Ответ на: комментарий от JFreeM

> А когда в середине записи данных в базу происходит внезапное отключение электричества, что Вы делаете?

Кидаем данные на другой узел.

pythonist
()
Ответ на: комментарий от JFreeM

>закопайте это УГ. noSQL бд не нужны.

Уж лучше nosql, чем EAV, с гипертрофированными таблицами и переусложнёнными запросами.

anonymous
()
Ответ на: комментарий от JFreeM

>Если Вы мне приведете пример, как работать с коллекцией в которой каждая запись имеет различный набор полей и соответствует различным обекьектам модели данных, я сниму перед Вами шляпу.

Приведите пример, как сделать коллекцию с разным набором полей и разными объектами модели данных в РСУБД.

//Язык, инструмент и теорию подбирают под задачу, а не наоборот.

anonymous
()
Ответ на: комментарий от JFreeM

> то есть, Вы считаете js - это хороший, годный язык для написания запросов к базе данных?

Где такое есть?

CouchDB поддерживает стандартно JavaScript для создания нового среза данных (вроде статического view). Питон подключается при необходимости стандартными средствами. Отдельный сервер обработки данных пишется на любом языке и связывается стандартными средствами с CouchDB. Роль для SQL при этом пропадает.

pythonist
()
Ответ на: комментарий от JFreeM

> Если Вы мне приведете пример, как работать с коллекцией в которой каждая запись имеет различный набор полей и соответствует различным обекьектам модели данных, я сниму перед Вами шляпу.

У нас так система и работает. Данные и структуры объектов с версиями хранятся в CouchDB. Уровень абстракции на Питоне. Я снимаю шляпу перед моими коллегами.

pythonist
()
Ответ на: комментарий от pythonist

>> Если Вы мне приведете пример, как работать с коллекцией в которой каждая запись имеет различный набор полей и соответствует различным обекьектам модели данных, я сниму перед Вами шляпу.

У нас так система и работает.

Запрограммировать можно всё - вопрос в том, как оно потом будет работать и как это развивать (ага, я знаю, что у вас оно отлично работает и легко развивается).

tailgunner ★★★★★
()
Ответ на: комментарий от AVL2

раз ты самый продвинутый просвети неучей как не порождая еще большие костыли сделать сложную манипуляцию с БД(состоящую из множества изменений)и при выключении электричества стихийном бедствии и прочей лабуде такой как одна из логических ошибок в цепочке откатить все назад(по принципу раз что то неверно значит весь пакет не верен).

grigoreo
()
Ответ на: комментарий от AVL2

вот и пускай идут в будущее а в настоящем пока альтернатив SQL нет а твои взахлеб песни про великие приемущества недоделаных продуктов это как минимум не серьезно (ну или годится для каких нибудь шарашек, где понятие целостности данных нафиг никому не надо)

grigoreo
()
Ответ на: комментарий от AVL2

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

grigoreo
()
Ответ на: комментарий от JFreeM

он так свою базу нагружает чтобы потом сказать что она у него толще(ну с детсва наверно не отвык еще мерятся ну ты понял чем)

grigoreo
()
Ответ на: комментарий от grigoreo

(шёпотом) оно много где никому не надо в том виде, который обеспечивают rdbms. например оно не надо твиттеру, фейсбуку и прочим фхкантагхтам.

Popil_Bablosov
()
Ответ на: комментарий от baverman

> Можете сказать, в каких задачах вам нужны транзакции? Пожалуйста, по-конкретнее, только.

Транзакции необходимы для обеспечения целостности данных. Когда изменяется не просто одна запись, а несколдько связанных. Без тразакций в результате сбоя целостность не обеспечить (без извращений).

А вообще, так это разные области применения. Если сложноструктурированные данные со множеством связей между таблицами, то никакой noSQL не поможет.

Skazochnik
()
Ответ на: комментарий от anonymous

ок, приведите пример задачи, для решения которой надо было бы так поступать

JFreeM ★★★☆
()
Ответ на: комментарий от JFreeM

>оу, то есть для Вас избыточность данных - это норма?

В природе не просто избыточность данных - норма, а ОГРОМНАЯ избыточность данных - норма :)

KRoN73 ★★★★★
()
Ответ на: комментарий от tarc

>Да и то, из крупных игроков их сейчас используют только единицы.

Ну так они и на рынок только выходить начинают. И то они уже работают под такими нагрузками, что просто сливай воду :) Facebook, Digg, eBay...

Вообще, есть интересное коммьюнити: http://community.livejournal.com/ru_highload Там иногда весьма приличные статьи бывают по теме.

KRoN73 ★★★★★
()
Ответ на: комментарий от grigoreo

>как не порождая еще большие костыли сделать сложную манипуляцию с БД(состоящую из множества изменений)и при выключении электричества стихийном бедствии и прочей лабуде такой как одна из логических ошибок в цепочке откатить все назад(по принципу раз что то неверно значит весь пакет не верен).

Другими словами, как без транзакций, костылей и велосипедов еще раз изобрести транзакции.

Тем не менее:

1) защита от сбоев электричества вообще никак не относится к транзакциям. Кто тебе вообще сказал подобную глупость?

2) Во всех случаях состояние БД является отражением, моделью некоего физического процесса. Купил клиент продукт - появилась запись в БД. Введение транзакций никак не помогает избежать рассинхронизации отражения с моделируемым процессом. То бишь клиент купил хлеба -> глюкнуло -> откат транзакции и что, у клиента не стало хлеба? Нет. На складе хлеба осталось столько же, сколько у тебя в базе? опять нет.

Транзакции, это примитивный, но очень дорогой способ обеспечить атомарность блоков операций с БД и только.

А теперь попробуй на транзакциях обеспечить решение всех этих проблем.

AVL2 ★★★★★
()
Ответ на: комментарий от pi11

>У CouchDB скорость была порядка 80 записей в секунду (у PostgreSQL не помню сколько но в разы меньше)

Это ты ещё учти, что CouchDB на порядок, наверное, тормознее, чем MongoDB :)

KRoN73 ★★★★★
()
Ответ на: комментарий от Skazochnik

>Транзакции необходимы для обеспечения целостности данных. Когда изменяется не просто одна запись, а несколдько связанных. Без тразакций в результате сбоя целостность не обеспечить (без извращений).

Внимание, вопрос, накуя тебе целостность данных.

Наводящий вопрос, потребуется ли тебе целостность данных в... nosql БД.

AVL2 ★★★★★
()
Ответ на: комментарий от matumba

>_Возможно_ НоСЫКУЛЬ найдёт своё место в вебе

Да давно уже нашёл у ведущих игроков. Вылезайте из анабиоза :)

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.