Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Дядька Адам говорит, что в общем-то он и сам не знает, какой она должна быть для распределенных RDBMS, но предполагает, что операции над схемами должны быть не атомарны, то есть во время ее обновления разных треды могут получать или новую или старую схему.
Ему вторит некто Алекс, говоря, что в мускуле она и так свободная, по тому что целостность только предполагается, а не гарантируется.
Ему вторит некто Алекс, говоря, что в мускуле она и так свободная, по тому что целостность только предполагается, а не гарантируется.
Видимо имеется ввиду, что установленная стандартом SQL система транзакций слишком жёсткая. Нужно иметь возможность вводить различные уровни транзакций в пределах одного запроса. Например их одной базы получать только подтверждённые данные из завершённых транзакций, а из другой — сырые (текущее состояние базы без учёта транзакций). Плюс, возможность, как это всё описывать на уровне метаданных.
Тогда можно делить одну базу на некие «непотопляемые отсеки» — наборы таблиц, операции над которыми атомарны, которые будут крутиться на разный физических серверах/кластерах. И можно будет строить очень сложную иерархию серверов.
Тогда можно делить одну базу на некие «непотопляемые отсеки» — наборы таблиц, операции над которыми атомарны, которые будут крутиться на разный физических серверах/кластерах. И можно будет строить очень сложную иерархию серверов.
Здраво. Но эксперименты с другими типами БД я из-за этого не закончу.
выходит, что единственный минус нереляционных бд — это возможная ненадежность разработчика, а в остальном делайте свои сервисы как получится…
хммм…
походу цепляются как могут за старую модель
хммм…
походу цепляются как могут за старую модель
ага. ну зачем нужна надежность? ну потеряет фейсбук пару десятков логинов. всего-то. это же меньше 0.1%.
те вы хотите сказать, что при падении вашего сервера с бд у вас все гладко восстановиться?
или при падении сервера с memcache данные фантастическим образом восстановяться в памяти?
или при падении сервера с memcache данные фантастическим образом восстановяться в памяти?
Репликацию в NoSQL никто не отменял. А упасть, как показывает практика может всё. Взять недавнюю историю твиттера.
Больше 12 часов потратили, базу так поднять и не смогли, подняли из копии. Сколько твиттов при этом умерло — нам думаю не расскажут.
Отталкиваться в любом случае нужно от потребностей (в т.ч. и по надежности) и выбирать соответствующие инструменты. Не стоит идеализировать не RDBMS не 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.
>единственное, для чего она там нужна — это поиск по входящим сообщениям
сколько шума было из за cassandra а оказалось они её почти не используют
сколько шума было из за cassandra а оказалось они её почти не используют
Рекомендую к прочтению — MongoDB или как разлюбить SQL
MongoDB не панацея. Да это может быть довольно эффективным решением на небольших кластерах. А когда речь идет о 1000 узлов, уже совершенно другой уровень монго в текущем его виде на мой взгляд еще большей геморрой чем в ручную шарденая sql база. Я думаю, сыроваты еще NoSql решения.
А вообще, Реляционных СУБД не существует в данный момент (тех которые отвечают всем 13 правилам Кодда). В них есть лишь некоторые из них. Ближе всех Oracle и PostgreSQL.
> Я думаю, что вся шумиха вокруг «NoSQL» сразу закончится, как кто-то наконец разработает распределнную реляционную базу со свободной семантикой.
Думаю, товарищ конкретно путает понятия «реляционность» и SQL.
Если г-дин Адам таки утверждает что JOIN это зло в РСУБД, то мне таки интересно что он понимает под реляционностью, между чем реляции (связи)?
Нет никакой проблемы реализовать foreign key'и в MongoDB и других БД, просто там это не нужно, потому что опять же нам не нужен JOIN, как мы уже выяснили.
> Я думаю, что вся шумиха вокруг «NoSQL» сразу закончится, как кто-то наконец разработает распределнную реляционную базу со свободной семантикой.
Думаю, товарищ конкретно путает понятия «реляционность» и SQL.
Если г-дин Адам таки утверждает что JOIN это зло в РСУБД, то мне таки интересно что он понимает под реляционностью, между чем реляции (связи)?
Нет никакой проблемы реализовать foreign key'и в MongoDB и других БД, просто там это не нужно, потому что опять же нам не нужен JOIN, как мы уже выяснили.
JOINы нельзя сделать между серверами, по этому разбивая данные по разным серверам нужно подойти к этому с умом, чтобы там, где джойны нужны, они были. Собственно за это «с умом» отвечает прослойка, которую придумали дядьки из FriendFeed
Такая разбивка на мой взгляд весьма глупое занятие, ведь можно упереться в толщину одного сервера. Хотя во многих случаях прокатит. Однако, это та же фигня что и server-side javascript в mongodb, с той лишь разницей что в mongodb это намного гибче.
Теоретически да, на практике у него еще куча репликантов и сам сервер не дохленький, посмотрите пункт 4.
Или, например, на то как это делает eve-online
Или, например, на то как это делает eve-online
если не ошибаюсь то JOINы между серверами все-таки можно делать, только вот скорее всего MySQL не умеет этого делать. Распределенные системы на MSSQL как минимум это позволяет. А уж думаю Oracle ему не уступает.
Под термином «реляционная» подразумевается не связь между таблицами, а сами таблицы (от математического термина отношение)
в одном проекте, который сильно вырос из физических возможностей MySQL поступил очень просто — часть таблиц лежит на одном сервере, часть на другом.
Часть таблиц используют встроеные partitions, часть разбивается ручками на разные таблицы.
При этом одна «формирующая» таблица может быть разбита на две-три, так чтобы ключики «лучше встали»
И конечно же разбитые таблицы будут на разных серверах…
Делается на самом деле очень просто — класс который выбирает нужную базу и требуемое имя таблицы на основе селектора — где-то 300 строчек
Главное это продумать изначально
Часть таблиц используют встроеные partitions, часть разбивается ручками на разные таблицы.
При этом одна «формирующая» таблица может быть разбита на две-три, так чтобы ключики «лучше встали»
И конечно же разбитые таблицы будут на разных серверах…
Делается на самом деле очень просто — класс который выбирает нужную базу и требуемое имя таблицы на основе селектора — где-то 300 строчек
Главное это продумать изначально
Мне вот известно, что Яндекс также экспериментировал с NoSQL. Redis, Cassandra, Mongo. Однако для широкого применения эти технологии не подошли — используется старая самописная система + кое-где SQL базы.
И данный подход я считаю правильным. Понаблюдать — понаблюдаем, но с переходом подождем.
И данный подход я считаю правильным. Понаблюдать — понаблюдаем, но с переходом подождем.
Redis не БД =)
Абсолютно. Я много с ним работал, даже написал драйвер для PHP нормальный, а не то убожество что там было.
Однако… это лишь жалкое подобие memcache с неуклюжим флушем на диск.
Однако… это лишь жалкое подобие memcache с неуклюжим флушем на диск.
при всем моем уважении к вам как разработчику это совершенно неправда! Мемкешу к нему как к небу, репликация и стор на диск (а теперь и VM) отлично работают.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Масштабируемость реляционных БД