The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Стабильный выпуск СУБД MariaDB 10.2, opennews (ok), 23-Май-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


6. "Стабильный выпуск СУБД MariaDB 10.2"  +/
Сообщение от MadeInRussia (?), 24-Май-17, 02:02 
Такая же немасштабируемая горизонтально прелесть, которая перекладывает сложность на уровень приложения либо дохнет как только получает сколько-нибудь весомый кусок данных и поток запросов?
Ответить | Правка | Наверх | Cообщить модератору

12. "Стабильный выпуск СУБД MariaDB 10.2"  +/
Сообщение от Gemorroj (ok), 24-Май-17, 08:31 
>> немасштабируемая горизонтально

galera же

Ответить | Правка | Наверх | Cообщить модератору

13. "Стабильный выпуск СУБД MariaDB 10.2"  –1 +/
Сообщение от пох (?), 24-Май-17, 09:33 
> Такая же немасштабируемая горизонтально прелесть, которая перекладывает сложность на
> уровень приложения либо дохнет как только получает сколько-нибудь весомый кусок данных
> и поток запросов?

как там внизу - "шел 2017й год", разработчики карманной тазы-банных для небольших сайтов без претензий на мировое господство все еще пытались выпилить из ее деталей оракл. stop... oh, shit...

зато уеб-девелоперы любят...

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

14. "Стабильный выпуск СУБД MariaDB 10.2"  +/
Сообщение от Аноним (-), 24-Май-17, 09:43 
Не забывай только, что сракл для метаданных использует BerkeleyDB
Ответить | Правка | Наверх | Cообщить модератору

15. "Стабильный выпуск СУБД MariaDB 10.2"  +/
Сообщение от пох (?), 24-Май-17, 10:06 
может, они ее готовить умеют? berkleyDB когда ее еще делали в berkley была (по тем временам, ни мемкэша ни sqlite даже в самых смелых мечтах еще не было) отличным хранилищем если тебе подходил формат key-value, но - для мелких задачек, умещающихся в локальной системе, не более.
Потом проект попал в руки эффективных, альтернатив во времена версии 2 толком не было, кто не опоздал родиться, тот до сих пор с содроганием вспоминает. Включая и bdb-backend самого mysql ;-)
Что там понаписали во времена "инвесторы любят большие числа" - пусть выясняют другие, я лучше в сторонке постою.

Ответить | Правка | Наверх | Cообщить модератору

30. "Стабильный выпуск СУБД MariaDB 10.2"  +1 +/
Сообщение от Аноним (-), 29-Май-17, 13:50 
>> Такая же немасштабируемая горизонтально прелесть, которая перекладывает сложность на
>> уровень приложения либо дохнет как только получает сколько-нибудь весомый кусок данных
>> и поток запросов?
> как там внизу - "шел 2017й год", разработчики карманной тазы-банных для небольших
> сайтов без претензий на мировое господство все еще пытались выпилить из
> ее деталей оракл. stop... oh, shit...
> зато уеб-девелоперы любят...

Ненене. Каждый сайт визитка должен быть на оркале. Корпоративные закупщики и прочие бенефециары всемерно одобряют.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

16. "Стабильный выпуск СУБД MariaDB 10.2"  +/
Сообщение от KonstantinB (ok), 24-Май-17, 11:40 
Про CAP-теорему напомнить? Невозможно сделать инструмент одновременно и масштабируемый и обеспечивающий целостность (не eventual, а полноценно).

Для разных задач - разные инструменты.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

17. "Стабильный выпуск СУБД MariaDB 10.2"  –1 +/
Сообщение от MadeInRussia (?), 24-Май-17, 12:28 
> Про CAP-теорему напомнить? Невозможно сделать инструмент одновременно и масштабируемый
> и обеспечивающий целостность (не eventual, а полноценно).
> Для разных задач - разные инструменты.

Можно. Если выбрать из CAP не AP, а CP и пожертвовать доступностью.

> Для разных задач - разные инструменты.

Согласен. Но если данных много, то так или иначе придется выбирать CP или AP, потому что вертикально масштабироваться — бомба замедленного действия. И лучше этот выбор продумать или заложить заранее. И здесь Maria — не в тему. Если же данных мало, то, скорее всего, уже текущей функциональности хватает для 99.99% кейсов.

Ответить | Правка | Наверх | Cообщить модератору

24. "Стабильный выпуск СУБД MariaDB 10.2"  +/
Сообщение от KonstantinB (ok), 25-Май-17, 08:03 
Да, имеем выбор между eventual consistency и eventual availability. Для второго РСУБД с шардингом вполне себе. Для первого - полно других инструментов.
Ответить | Правка | Наверх | Cообщить модератору

26. "Стабильный выпуск СУБД MariaDB 10.2"  –1 +/
Сообщение от MadeInRussia (?), 25-Май-17, 23:44 
> Да, имеем выбор между eventual consistency и eventual availability. Для второго РСУБД
> с шардингом вполне себе. Для первого - полно других инструментов.
> Для второго РСУБД с шардингом вполне себе.

Вот только шардинг на РСУБД — это то еще веселье.

Ответить | Правка | Наверх | Cообщить модератору

27. "Стабильный выпуск СУБД MariaDB 10.2"  +1 +/
Сообщение от KonstantinB (ok), 26-Май-17, 20:59 
Уж мне ли не знать, я с этим работал еще 10 лет назад.
Отдельное веселье с mysql-ем с нетранзакционным DDL - на лету создавать дополнительные таблицы просто опасно. Приходится заранее прогнозировать и аллоцировать.

Сейчас чуточку проще стало, есть всякие ProxySQL/Kingshard. Хотя, в принципе, примерно такой же код, только на уровне инфраструктурного слоя приложения, и у меня был.

Ответить | Правка | Наверх | Cообщить модератору

31. "Стабильный выпуск СУБД MariaDB 10.2"  +/
Сообщение от MadeInRussia (?), 02-Июн-17, 13:21 
>>> Для второго РСУБД с шардингом вполне себе.
>Уж мне ли не знать, я с этим работал еще 10 лет назад.

Так может РСУБД все же не лучший инструмент для этих задач? Если когда данных становится много, приходится бегать с бубнами, плакать, есть кактус и пытаться всунуть в него шардинг после чего не дышать, чтобы оно не сдохло.

А когда уже не хватает серверов и приходится делать ребалансировку? А распределение таблиц так, чтобы все нужные JOIN-ы работали? А распределенные JOIN-ы, если они понадобились? Все это будет болью и мучениями.

И РСУБД нужно для этих целей выбирать потому что... ? Потому что лет 10, ну или даже 5, назад это было лучшим решением для этих целей? Когда-то лошадь была лучшим решением для быстрого перемещения на большие расстояния, если две точки соединены сушей. Вот только потом появился автомобиль, построенный на других принципах. А потом — поезд. А потом — самолет.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру