Вышел CouchDB 1.0

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

ДБ на эрланге? Мнезиа уже есть, ага. Закапывайте поглубже, чтоб не воняло.

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

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

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

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

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

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

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

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

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

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

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

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

Обычный insert по одной записи в обоих случаях.

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

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

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

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

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

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

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

а у вас база была 150гб или табличка в которую инсертили?

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

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

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

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

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

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

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

есть подозрение что «обработать и положить в другую табличку» без транзакций не получится надежно.

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

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

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

В сабже - мат фундамент это B-trees.

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

Это как оно унутре устроено. А вопрос был про что-то типа реляционной алгебры.

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

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

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

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

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

> Сейчас с mongo мучаюсь

Ограничения в MongoDB на 32-х битах: 2,5 ГБ

http://blog.mongodb.org/post/137788967/32-bit-limitations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тем не менее:

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

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

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

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

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

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

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

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

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

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

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