Перевод интервью с разработчиком Twitter о переходе на Cassandra

>Мда? Может я чего-то не понимаю, с удовольствием послушаю объяснения каким образом 2D-таблица реляционная?

С тех пор как появляются Foreign Key и не появляется порядок строк в таблице.

>И каким образом СУБД без базы (совокупности связанных таблиц) становится реляционной?

Ну как-бы Relation это и есть связь, отношение....

>Как только появятся доступные и работоспособные DBFS - так сразу! :)

Не под тем углом смотрите. Сейчас Очень часто ORM->СУБД->FS (Кстати FS не обязателен, ну или я могу сразу выделять под БД гиг.... )

А вот если мы храним данные о кадрах предприятия, согласитесь просто LDAP может дать бооооооольшой прирост в производительности. Просто девелоперы знают SQL, но не LDAP. А есть еще куча разных БД. Я уже упомянул FramerD который по данным разработчиков вообще оракл порвет....

Имею ввиду обычную таблиц - двумерную матрицу.

Матрицы:

aaa
bbb
ccc

и

aaa
ccc
bbb

Разные, а вот с точки зрения реляционной теории порядок следования кортежей не играет роли, а устанавливается явно в запросе.

>> Как получить из ФС результат вида «вывести всех пользователей, которые запостили на форум с 21 до 23 часов 25 февраля 2010 года от 2 до 3 сообщений»

По философствую )) Как на счет того что бы включить в ФС эвристический анализ :) ну и те же транзакции по вкусу.

>По философствую )) Как на счет того что бы включить в ФС эвристический анализ :) ну и те же транзакции по вкусу.

Не философствуй. Эвристика тут не причем. Индексы не только в СУБД существуют. Их более 10 лет используют в продакшене и в других БД, я потом назову одну....

Следовательно объявляя индекс сразу получаем ответ, что есть аналог планировщику. Опять-же поглядите как организованы запросы в FramerD

Просто в ФС хочется введения произвольных атрибутов и быстрого поиска по их индексам.

Что-то типа LDAP, но с возможностью хранить большие объёмы данных?

КО наивно забывает про транзакции на изменение данных (а не только метаданных) и уровни изоляции, консистентность на чтение (MVCC) и репликацию. + SQL язык запросов + триггеры и хранимки.

Это детали реализации. SQL - вообще мимо.

>Что-то типа LDAP, но с возможностью хранить большие объёмы данных?

Данные, не большие по объёму, но большие по количеству. Те же тэги для фото, видео и музыки. Чтобы можно было одним запросом выдернуть, например, все фото, отснятые в прошлом году и у которых в тэге ключевых слов есть «праздник».

LDAP - не знаю, подходит ли. Там, разве, есть эффективные запросы по диапазонам параметров?

> А еще NoSQL это не база данных. Хотя в названии не сказано NoDatabase. Скорее не реляционная.

внимательное гугление дает перевод NoSQL как «не только реляционная».

Иерархические, сетевые, объектные СУБД это весело и забавно... только подходят они для частных случаев. В общем случае лучше работают реляционные.

Капец просто. SQL - *линейная* база данных. SQL вроде был всегда языком структурированных запросов к базе данных, обычно реляционной. Но если здесь собрались такие фантазёры, то ничего не мешает создать реализация SQL к любой другой базе данных, например древовидной, и будет вам «количество пользователей запостивших с 23-00...» или как там

> По философствую )) Как на счет того что бы включить в ФС эвристический анализ :) ну и те же транзакции по вкусу.

философия: а зачем? unix way и бритва Оккама затупятся ;)

ФС выполняет одну функцию, РСУБД - другую. Затачивать одно на другое может быть сложно и бессмысленно.

Одна из самых сложных систем РСУБД - оптимизатор запросов. В ФС по большей части он не нужен ибо ФС не является реляционной и join в ней не сделать.

> Но если здесь собрались такие фантазёры, то ничего не мешает создать реализация SQL к любой другой базе данных, например древовидной, и будет вам «количество пользователей запостивших с 23-00...» или как там

конечно можно эмулировать реляционку поверх древовидной ФС. все упирается в скорость работы и надежность. Как вы в ФС внешние ключи сделаете? а триггеры?

>Конечно можно эмулировать реляционку поверх древовидной ФС. все упирается в скорость работы и надежность.

Охотно верю что это будет не просто но и не считаю что вообще нужно и не призываю кого-либо это делать. Я лишь обращал внимание на подмену и/или непонимание понятий.

LDAP - не знаю, подходит ли. Там, разве, есть эффективные запросы по диапазонам параметров?

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

>LDAP - не знаю, подходит ли. Там, разве, есть эффективные запросы по диапазонам параметров?

Вопрос нужности. Апачевский LDAP умеет вьюшки, хранимки и триггеры.. Так, что если надо думаю сделают

http://forums.sun.com/thread.jspa?messageID=3267962

А еще есть ZODB, десятилетия там ищут и очень быстро когда индексы созданы

Уж точно быстрее MySQL

Дело-то не в LDAP. Да хоть CouchDB. Лишь бы с FS интегрировано было :)

>интересно. а разве MySQL Cluster не все три сразу свойства имеет?

Поскольку применяется MySQL как обработчик данных то БД получает ACID. +C

А разве там реалтайм репликация? Наверняка нужно время чтобы это расползлось по нодам. А в таком случает нет +С, потому что сделали апдейт, потом сразу селект, попали на еще необновленную ноду и получили старые данные.

> Становится понятно, что оно не консистентно... не понятно вообще Кассандра поддерживает ли транзакции? и каким образом?

На уровне приложения транзакции реализуются где угодно, хоть в gdbm.

> Как получить из ФС результат вида «вывести всех пользователей, которые запостили на форум с 21 до 23 часов 25 февраля 2010 года от 2 до 3 сообщений»

На ФС придется циклом идти по всем пользователям.

Зачем? Делается проще. Все сообщения пишутся в плоскую таблицу в порядке написания, т.е. они уже отсортированы по времени. Выбираешь range 2010-02-25 21:00 - 2010-02-25 23:00, строишь в памяти список 'пользователь=>кол-во сообщений', сортируешь, выборка с range > 3. Всё очень быстро происходит. Будет работать эффективно даже в случае, если вместо СУБД используется файловая система. Ты думаешь классические СУБД делают это как-то иначе? Всё то же самое. В данном случае главное - никаких лишних или непонятных движений, и никаких ожиданий чуда от SQL-оптимизатора. Всё в твоих руках. Ты знаешь, что ты хочешь сделать, и то, что ты делаешь. Автоматическая коробка передач против ручной ;)

>Дело-то не в LDAP. Да хоть CouchDB. Лишь бы с FS интегрировано было :)

Я про LDAP говорь, потому, что ему 100 лет в обед и для ряда задач он лучше подходит. Но найди приложения которые его используют кроме как для хранения Юзеров и учеток машин. Те, же паспорта для отдела кадров хранить самое оно. Есть фото поля есть еще куча всякого. Разработчики просто не знакомы.

Обычно выучат реляционные базы и везде их применяют....

LDAP слишком сложен для простого, и слишком примитивен для сложного. В этом его грабли и ограничения. Хранить данные юзеров с таким же успехом можно на файловой системе по принципу один юзер = один файл с данными. На каждый файл назначай отдельные права для соблюдения конфиденциальности. Читай файлы хоть через самбу, хоть через ssh или ftp. Тут тебе и иерархия, и права доступа, и криптозащита канала при желании. Зачем изобретали велосипедный LDAP - непонятно.

>Зачем изобретали велосипедный LDAP - непонятно.

Репликация, доступ на уровне полей можно расписать. Поиск. LDAP на самом деле очень хорошая штука.

Еще учти в LDAP ты не запишишь фотку в телефонное поле. Там четко схема есть. Типизация

>Обычно выучат реляционные базы и везде их применяют....

Оно намного проще. Я несколько лет назад пытался применить LDAP для хранения авторизационных данных на форуме. За пару дней ковыряний так ничего и не понял. А вот с MySQL за несколько лет до того, имея скилл намного более низкий, работать сумел сразу же. При чём касалось это и установки/настройки и собственно работы.

Думаю, это уже ответ, почему SQL популярнее :)

>Имею ввиду обычную таблиц - двумерную матрицу.

Таблица в БД != двумерная матрица.

>> интересно. а разве MySQL Cluster не все три сразу свойства имеет?

Поскольку применяется MySQL как обработчик данных то БД получает ACID. +C

А разве там реалтайм репликация? Наверняка нужно время чтобы это расползлось по нодам. А в таком случает нет +С, потому что сделали апдейт, потом сразу селект, попали на еще необновленную ноду и получили старые данные.

там не репликация вообще ;) в каждой группе есть ноды ответственные за хранение. Групп может быть и больше 2-х.

Делаем апдейт + коммит. Коммит висит до тех пор пока ВСЕ группы не откликнутся что апдейт применили.

Делаем селект - все группы обновлены, потому селект по любой группе выдаст правильные данные.

>> Становится понятно, что оно не консистентно... не понятно вообще Кассандра поддерживает ли транзакции? и каким образом?

На уровне приложения транзакции реализуются где угодно, хоть в gdbm.

на уровне приложение это не транзакции а лапша и надежда, что приложение не упадет в ненужный момент. Или свич не выключится или еще чего...

СУБД отвечает за то, что даже если транзакция не была завершена - БД останется в консистентном состоянии.

> Зачем? Делается проще. Все сообщения пишутся в плоскую таблицу в порядке написания, т.е. они уже отсортированы по времени.

Это предподготовка данных. А если мне по тем же данным нужно и иные разрезы делать?

И вообще зачем мне сажать разраба чтобы он затачивал данные под конкретный вид запросов если я могу загнать все данные в СУБД, а скорость запросов тюнить наличием индексов.

PS хранить в заранее отсортированном виде таблицы умеет даже MS SQL еще с лохматых версий. Только это чаще мешает, чем помогает.

>Думаю, это уже ответ, почему SQL популярнее :)

Больше спецов - больше мануалов. Я когда начал делать свои LDAP схемы прям влюбился в него. А не делать схемы == не создавать таблиц.

> Я про LDAP говорь, потому, что ему 100 лет в обед и для ряда задач он лучше подходит. Но найди приложения которые его используют кроме как для хранения Юзеров и учеток машин. Те, же паспорта для отдела кадров хранить самое оно. Есть фото поля есть еще куча всякого. Разработчики просто не знакомы.

Обычно выучат реляционные базы и везде их применяют....

РСУБД проще объяснить - их даже в вузах проходят.Системы хранения контента вообще в РСУБД хранят иерархии данных и атрибуты ;)

>PS хранить в заранее отсортированном виде таблицы умеет даже MS SQL еще с лохматых версий. Только это чаще мешает, чем помогает.

Нет такой СУБД. Тоесть продается, но это Сайбэйс. Они позвонили в Сайбэйс и предложили оптимизировать их СУБД по НТ. Спустя два года появился МС СКУЭЛЬ. А еще они предложили Цитриксу оптимизировать РДП для НТ. И появился 2000 Терминал Сервер. А в Офис Цитрикса в NY влетел самолет :-) Поинтересуйтесь историей разработок

>Больше спецов - больше мануалов.

Вряд ли дело в мануалах. MySQL я в своё время без всяких мануалов осваивал, на основе phpmyadmin и знании английского :)

с фига ли?

Сайбейзом создан (или куплен) Sybase ASE на базе которого и появились MS SQL server'а. По данным википедии MS SQL 6.0 был первым сервером который разрабатывался без участия Sybase. После него еще множество версий вышло независимо от исходного продукта.

Так что MS SQL это собственный сервер MS, хотя когда то и был приобретен ими.

И да, это практически единственный качественный продукт выпускаемый майкрософт. По крайней мере был таким в 2к версии. Позже с ним не работал.

>Вряд ли дело в мануалах. MySQL я в своё время без всяких мануалов осваивал, на основе phpmyadmin и знании английского :)

А аналог для LDAP нету. Консоль и все. А примеров написания схем вообще. Я когда свою составил несколько обалдел. - в том, чо номера атрибутов надо зарегистрировать. Но для поиграться можно и так. + Маппинг подветвей это сила. +Вьюшки.

2VoDA - не правда. Есть разница между вам показали направление и вы пошли им или вы сами его выбрали. Взять протокол, способ хранения и вообще кучу всего и сделать рефакторинг. Ну не учавствовал Сайбэйс там. Но направление то. Почему провалился Мультиплан?

А аналог для LDAP нету. Консоль и все.

$ eix phpldap
[I] net-nds/phpldapadmin
     Available versions:  (1.2.0.4) (~)1.2.0.4
	{vhosts}
     Installed versions:  1.2.0.4(1.2.0.4)(10:34:48 11.10.2009)(vhosts)
     Homepage:            http://phpldapadmin.sourceforge.net
     Description:         phpLDAPadmin is a web-based tool for managing all aspects of your LDAP server.

Одна беда - под него требуется уже работающий настроенный сервер. А это задача намного более сложная, чем в случае mysql :)

>Одна беда - под него требуется уже работающий настроенный сервер. А это задача намного более сложная, чем в случае mysql :)

Во-во. Фигня это я пользую GQ но опять-же схемы нужны заранее. Тоесть с SQL мы начинаем с схем. А с LDAP это вроде как экзотика. Неверный методический подход. Но MS не зря в фундамент AD положил LDAP. Он недооценен. Это как функциональное программирование в императивных языках. Количество коллбэков у меня возросло с 1% до 70%. Так, что стоит помоему.