resurection Сообщение 11/01/2011 14:46 Копия темы
MySQL: Раскидать таблицы по разным серверам Есть две связанные таблицы. В нескольких местах используются вложенные запросы и join-ы. Можно ли раскидать эти таблицы на физически разные сервера?
Естественно, не переписывая СКЛ-запросы.

idle Сообщение 11/01/2011 14:50 Копия темы
Теоретически всё можно.
Но эта затея бессмысленна.

resurection Сообщение 11/01/2011 14:53 Копия темы

resurection Сообщение 11/01/2011 14:58 Копия темы
смысл в том, что бы распараллелить нагрузку. Вместо кластеризации с репликацией (дублированием данных) – разложить всё по полочкам. Список юзеров на одном сервере, а список комментов на другом. И над отображением одного треда будут трудится два разных сервера – первый выбирает юзеров, а другой комменты.

idle Сообщение 11/01/2011 15:03 Копия темы
Кластеризация с репликацией и есть самый эффективный способ распараллеливания. Так как Вы хотите не выйдет, увы.
Переходите на postgresql если не поздно.

resurection Сообщение 11/01/2011 15:14 Копия темы
Зависит от задач. Есть, таблица с логами. У неё есть особенности: она очень большая и логи не удаляются и не изменяются; они только добавляются. Я не спец по настройкам т.к. не сисадмин, но, мне кажется, если выделить под логи отдельный дедикейтед сервер, то его можно будет хорошо оптимизировать. Подозреваю, что дело даже не ограничится настройками МуСКЛа, а дойдёт вплоть до ФС. А может даже вместо МуСКЛа завести МариюДБ для логов?

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

А кластеризация для логов – это, наверное, не совсем правильно т.к. очень много инсёртов. И дублирование большого объёма инфы – это лишнее.

idle Сообщение 11/01/2011 15:25 Копия темы
С какими логами? Почему не удаляются? 

>не спец по настройкам т.к. не сисадмин
Так поручите спецу.

resurection Сообщение 11/01/2011 15:35 Копия темы
Это не access.log для апача. Логи – важная часть системы и они не должны удалятся.

> Так поручите спецу. 
Если можно распараллелить, то поручим спецу. Но это пока далёкая перспектива. А мне сейчас уже нужно программить и выстроить архитектуру. Есть же другой вариант. Я на стороне клиента умею джоинить. Подключится к двум разным серверам, выбрать логи, потом из логов выбрать user_id и из другого сервера вытащить юзеров SELECT .... WHERE `id` IN (25, 23, 44, ...) – в результате получаю два массива и могу отобразить список логов с их авторами.

idle Сообщение 11/01/2011 15:47 Копия темы
Я догадываюсь что не от апача. Потому и спрашиваю что за логи?
Может их можно хранить в RRD, где размер не меняется в зависимости от времени хранения.
А программить, не определившись с архитектурой – плохая затея. :-/

resurection Сообщение 11/01/2011 16:10 Копия темы
Ещё практическая задачка.
Наш юрист хочет что бы таблица users была на трёх разных серверах. Это требуется по какому-то ГОСТу согласно Федеральному Закону о хранении персональных данных.
Я могу раскидать таблицу users на 3 разных таблицы и объединить их в один view. Остаётся открытым вопрос о том, что бы 3 таблицы разложить по серверам.

terrainc Сообщение 11/01/2011 16:29 Копия темы
Ваша идея даст оверхед – сначала данные займут память на одном сервере, потом передача по сети и кушание памяти на другом сервере, который уже будет делать итоговый джойн.

terrainc Сообщение 11/01/2011 16:42 Копия темы
Теоретически можно partitioning и файлы таблиц раскидать по разным серверам и смонтировать по сети. Я бы не рискнул.
В 99% случаев это решается на уровне приложения.

resurection Сообщение 11/01/2011 16:45 Копия темы
Для этого придётся всё приложение переписать.

terrainc Сообщение 11/01/2011 16:56 Копия темы
Как правило не все. Если, конечно, это не говнокод с рассованными куда попало запросами ;)
Посмотрите еще такую штуку spockproxy.sourceforge.ne..., но я о ней что-то не слышал раньше, так что хз насколько оно юзабельно. Может можно на mysqlproxy написать что-то подобное и самому.

terrainc Сообщение 11/01/2011 17:01 Копия темы
Ну или сразу переходить к NDB. Там по архитектуре уже partitioning. И распределение нагрузки есть и все такое. Правда, многие вещи NDB не любит и бъет сильно производительностью. В частности те же джойны со сложными выборками.

resurection Сообщение 11/01/2011 17:02 Копия темы
Кончено переписать придётся только Model у MVC, но это всё равно дольше, чем сделать один view. Да и я пока не представляю как заменить один запрос SELECT ... WHERE `role`='owner' AND `phone`='1234567' на два запроса к разным серверам. А потом ещё результаты выборки надо будет перемножать (я об операции перемножения множества). Аналогично для запроса SELECT ... ORDER BY `login`, `phone`.

terrainc Сообщение 11/01/2011 17:08 Копия темы
Да, именно так. Зато управление распределением на совести приложения, что дает очень гибкие возможности управления распределением – куда что класть. Например, если у вас две таблицы – пользователи и логи, то можно шардить логи на основе user_id, и таким образом эффективно использовать джойн, ибо он не будет выходить за рамки одного сервера.

resurection Сообщение 11/01/2011 17:30 Копия темы
Это другая ветка. Про разделение таблицы users на 3 таблицы – актуальнее. По закону персональные данные должны быть разбиты на три группы и хранится на разных серверах: личные (ФИО, ДР, ... ), финансовые (обороты, прибыль, ...) и контактные (адрес, телефоны, мыло, ICQ).

И есть запрос: SELECT ... WHERE `role`='client' AND `town`='Москва' ORDER BY `tariff`; // найти всех клиентов из Москвы и отсортировать по тарифу.

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

terrainc Сообщение 11/01/2011 17:47 Копия темы
А.... посмотрите dev.mysql.com/doc/refman/...

resurection Сообщение 11/01/2011 18:22 Копия темы
К сожалению не подходит
There is no support for transactions

хотя надо тестить. Подозреваю, что это может быть ограничением удалённой таблицы.

terrainc Сообщение 11/01/2011 18:31 Копия темы
Я полагаю, вы хорошо представляете – зачем нужны транзакции применительно к вашему случаю.

Другой вариант – использовать сервера как хранилища и монтировать по DRBD таблицы на общий SQL сервер. Только вот там сплошное кеширование, что с точки зрения безопасности не есть хорошо – на SQL сервере будут копии всех таблиц доступны.

abbat Сообщение 11/01/2011 18:54 Копия темы
Задача хранения логов хорошо решается при помощи MongoDB – у нее и с производительностью получше и с возможностью легкого шардинга/репликации. Технология map/reduce позволит прозрачно "join-ить" (хотя данный термин здесь будет не совсем корректен) необходимые данные с необходимого количества серверов и горизонтальное масштабирование становится почти административной задачей. К сожалению, это потребует некоторой смены парадигмы на документо-ориентированную БД вместо привычной реляционки, но оно того стоит в данном конкретном случае.

Если все же требуется оставаться в рамках MySQL, то:

а) экспериментировать с производительностью лучше на базе XtraDB и Percona Server вместо MariaDB;
б) про использование NDB/FEDERATED лучше не вспоминать, если нет толстых стабильных каналов между серверами (а их в 99% случаев нет);
в1) выборки строить через MySQL Proxy + Lua – это позволит не переписывать запросы, но попрощаться с личной жизнью.
в2) выборки строить разбивая запросы на уровне приложения – в случае сложных запросов рано или поздно архитектура придет к тому же map/reduce через что-то типа Gearman (ну а когда скиллы будут прокачаны до уровня Gearman, то ни база, ни запросы уже особого значения иметь не будут).

Как-то так.