Масштабируемость реляционных БД

[sylvio]

Дядька Адам говорит, что в общем-то он и сам не знает, какой она должна быть для распределенных RDBMS, но предполагает, что операции над схемами должны быть не атомарны, то есть во время ее обновления разных треды могут получать или новую или старую схему.

Ему вторит некто Алекс, говоря, что в мускуле она и так свободная, по тому что целостность только предполагается, а не гарантируется.

[Sap_ru]

Видимо имеется ввиду, что установленная стандартом SQL система транзакций слишком жёсткая. Нужно иметь возможность вводить различные уровни транзакций в пределах одного запроса. Например их одной базы получать только подтверждённые данные из завершённых транзакций, а из другой — сырые (текущее состояние базы без учёта транзакций). Плюс, возможность, как это всё описывать на уровне метаданных.
Тогда можно делить одну базу на некие «непотопляемые отсеки» — наборы таблиц, операции над которыми атомарны, которые будут крутиться на разный физических серверах/кластерах. И можно будет строить очень сложную иерархию серверов.

[proxiper]

Здраво. Но эксперименты с другими типами БД я из-за этого не закончу.

[Masterkey]

выходит, что единственный минус нереляционных бд — это возможная ненадежность разработчика, а в остальном делайте свои сервисы как получится…
хммм…
походу цепляются как могут за старую модель

[JustLuckyGuy]

ага. ну зачем нужна надежность? ну потеряет фейсбук пару десятков логинов. всего-то. это же меньше 0.1%.

[Masterkey]

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

[Nc_Soft]

в memcache ничего такого важного хранить нельзя

[VasilioRuzanni]

Ну как сказать — важность там ни при чем, это же кэш, в нем можно хранить все, что угодно. Вопрос только в том, что _источником_ любых важных данных должен быть не mc.

[Shedar]

Репликацию в NoSQL никто не отменял. А упасть, как показывает практика может всё. Взять недавнюю историю твиттера.

To remedy the locked table, we force-restarted the database server in recovery mode, a process that took more than 12 hours (the database covers records for more than 125 million users — that’s a lot of records). During the recovery, the users table and related tables remained unavailable. Unfortunately, even after the recovery process completed, the table remained in an unusable state. Finally, yesterday morning we replaced the partially-locked user db with a copy that was fully available

Больше 12 часов потратили, базу так поднять и не смогли, подняли из копии. Сколько твиттов при этом умерло — нам думаю не расскажут.
Отталкиваться в любом случае нужно от потребностей (в т.ч. и по надежности) и выбирать соответствующие инструменты. Не стоит идеализировать не RDBMS не NoSQL.

[Masterkey]

непарься, видимо тут SQL головного мозга )

[Homakov]

>единственное, для чего она там нужна — это поиск по входящим сообщениям
сколько шума было из за cassandra а оказалось они её почти не используют

[Shedar]

у фейсбука даже это «всего-лишь» — порядка 150-200 серверов.

[AmirL]

Из многих тысяч.

[TravisBickle]

Рекомендую к прочтению — MongoDB или как разлюбить SQL

[sys]

MongoDB не панацея. Да это может быть довольно эффективным решением на небольших кластерах. А когда речь идет о 1000 узлов, уже совершенно другой уровень монго в текущем его виде на мой взгляд еще большей геморрой чем в ручную шарденая sql база. Я думаю, сыроваты еще NoSql решения.

[Masterkey]

панацеи впринципе не может быть.
тыкните плиз в то место где монго слабоват.
1000 узлов обосновано тем, что они используют mysql.

[sys]

Группировка к примеру не работает на распределенных базах.
MapReduce пока работает в single-thread режиме, что не позволяет утилизировать более одного ядра и распараллелить как следует задачу. А вся соль MapReduce в том, что эти операции можно легко распараллеливать.

[TravisBickle]

А вообще, Реляционных СУБД не существует в данный момент (тех которые отвечают всем 13 правилам Кодда). В них есть лишь некоторые из них. Ближе всех Oracle и PostgreSQL.

> Я думаю, что вся шумиха вокруг «NoSQL» сразу закончится, как кто-то наконец разработает распределнную реляционную базу со свободной семантикой.
Думаю, товарищ конкретно путает понятия «реляционность» и SQL.

Если г-дин Адам таки утверждает что JOIN это зло в РСУБД, то мне таки интересно что он понимает под реляционностью, между чем реляции (связи)?

Нет никакой проблемы реализовать foreign key'и в MongoDB и других БД, просто там это не нужно, потому что опять же нам не нужен JOIN, как мы уже выяснили.

[sylvio]

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

[TravisBickle]

Такая разбивка на мой взгляд весьма глупое занятие, ведь можно упереться в толщину одного сервера. Хотя во многих случаях прокатит. Однако, это та же фигня что и server-side javascript в mongodb, с той лишь разницей что в mongodb это намного гибче.

[sylvio]

Теоретически да, на практике у него еще куча репликантов и сам сервер не дохленький, посмотрите пункт 4.
Или, например, на то как это делает eve-online

[VelarThind]

если не ошибаюсь то JOINы между серверами все-таки можно делать, только вот скорее всего MySQL не умеет этого делать. Распределенные системы на MSSQL как минимум это позволяет. А уж думаю Oracle ему не уступает.

[TEHEK]

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

[kashey]

в одном проекте, который сильно вырос из физических возможностей MySQL поступил очень просто — часть таблиц лежит на одном сервере, часть на другом.
Часть таблиц используют встроеные partitions, часть разбивается ручками на разные таблицы.
При этом одна «формирующая» таблица может быть разбита на две-три, так чтобы ключики «лучше встали»
И конечно же разбитые таблицы будут на разных серверах…

Делается на самом деле очень просто — класс который выбирает нужную базу и требуемое имя таблицы на основе селектора — где-то 300 строчек

Главное это продумать изначально

[bethrezen]

Мне вот известно, что Яндекс также экспериментировал с NoSQL. Redis, Cassandra, Mongo. Однако для широкого применения эти технологии не подошли — используется старая самописная система + кое-где SQL базы.
И данный подход я считаю правильным. Понаблюдать — понаблюдаем, но с переходом подождем.

[TravisBickle]

Redis не БД =)

[Egorkin]

Уверены?

[TravisBickle]

Абсолютно. Я много с ним работал, даже написал драйвер для PHP нормальный, а не то убожество что там было.
Однако… это лишь жалкое подобие memcache с неуклюжим флушем на диск.

[aleks_raiden]

при всем моем уважении к вам как разработчику это совершенно неправда! Мемкешу к нему как к небу, репликация и стор на диск (а теперь и VM) отлично работают.

[TravisBickle]

Redis жеж однотредовый, а memcached на pthreads. Чтоб выжрать ресурсы одной тачки с двумя quad-xeon'ами на борту предлагается запустить там 16 редисов на разных портах. Ну не бред ли?

[aleks_raiden]

в чем проблема? Множество современных решений, мощнейших, однотредовые. Nginx, NodeJS. И, кстати, Redis не совсем однотредовый, может использовать несколько, разнося фоновые операции

[TravisBickle]

Nginx вообще-то порождает заданное количество рабочих процессов самостоятельно.