Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > Скриптовые языки программирования > PHP
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 12.11.2015, 19:21   #1
CodeNOT
Форумчанин
 
Аватар для CodeNOT
 
Регистрация: 08.11.2010
Сообщений: 593
По умолчанию Шардинг БД

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

Но суть вот в чем, есть таблица в mysql, назовем ее logs
таблица весит 115 ГБ, операции поиска и выборки стали занимать уйму времени и насиловать мускул, собственно логичное решение или дропнуть часть данных (что непозволительно) или разибить ее на две и более таблиц, теперь у меня собственно к вам вопрос, есть ли в mysql какой либо механизм. который позволяет разбивать таблицы без правки запросов.
предположим, что в таблица 1 000 000 000 строк, и я решил разбить ее на 10 таблиц, при этом насколько я понимаю, если я делаю тот же поиск мне придется переделывать запрос на все 10 таблиц? т.е. предположим был такой запрос

Код:
SELECT * FROM logs WHERE some_field=som_value LIMIT 0,1000
получается по логике я должен его выполнить теперь ко всем 10 таблицам, но для этих целей нет ли каких-то средств автоматизации на стороне mysql?

Надеюсь объяснил понятно, голова уже не варит.
CodeNOT вне форума Ответить с цитированием
Старый 12.11.2015, 20:16   #2
Stilet
Белик Виталий :)
Старожил
 
Аватар для Stilet
 
Регистрация: 23.07.2007
Сообщений: 57,792
По умолчанию

Индексация таблицы не рассматривается?
I'm learning to live...
Stilet вне форума Ответить с цитированием
Старый 12.11.2015, 20:49   #3
Аватар
Старожил
 
Аватар для Аватар
 
Регистрация: 17.11.2010
Сообщений: 19,042
По умолчанию

Цитата:
получается по логике я должен его выполнить теперь ко всем 10 таблицам, но для этих целей нет ли каких-то средств автоматизации на стороне mysql
Можно конечно, сделав представление, в котором UNION объединяет несколько таблиц. Только не поможет, а усугубит при всех прочих равных условиях. Тоже бы на индексах сосредоточился в первую очередь
Если бы архитекторы строили здания так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию
Аватар вне форума Ответить с цитированием
Старый 12.11.2015, 22:51   #4
CodeNOT
Форумчанин
 
Аватар для CodeNOT
 
Регистрация: 08.11.2010
Сообщений: 593
По умолчанию

Собственно с индексами сейчас работаю и пересоздаю, просто было интересно, возможно ли это. А вообще как вы решаете вопрос как раз с такими данными? при этом они должны быть, т.е. удалять их нельзя, на nosql переводите?
CodeNOT вне форума Ответить с цитированием
Старый 13.11.2015, 00:13   #5
Andkorol
Старожил
 
Регистрация: 31.05.2010
Сообщений: 3,301
По умолчанию

Цитата:
Сообщение от CodeNOT Посмотреть сообщение
А вообще как вы решаете вопрос как раз с такими данными? при этом они должны быть, т.е. удалять их нельзя, на nosql переводите?
Теоретически – любые данные (с целью уменьшения их суммарного объёма в рамках одной таблицы) можно разделить на фрагменты по какому-либо признаку, например по дате/времени создания – что весьма удобно для логов, кстати.
Соответственно, поиск по таким разделенным данным происходит каскадно, до получения нужных результатов, или же по каким-либо другим ограничительным признакам.
На практике – это всё очень зависит от специфики данных, и угадать оптимальный вариант здесь сложно.
И noSQL в таких вопросах далеко не всегда есть панацея, увы. Там тоже не всё так радужно на больших объёмах данных.
Andkorol вне форума Ответить с цитированием
Старый 13.11.2015, 01:36   #6
Keyup
Новичок
Джуниор
 
Регистрация: 11.11.2015
Сообщений: 2
По умолчанию

Уйму времени - это больше одной секунды?
Запрос, который Вы показали очень легкий и 115гб не так уж много для него.
Если Вы хотите решить Вашу проблему, то найдите причину, почему Ваш запрос работает медленно.
Сейчас Ваш запрос может тормозить по причине забитости сети (LIMIT 1000 может долго передаваться по сети).
Вы не указали тип таблиц. В MySQL есть несколько типов таблиц и некоторые из них делают блокировки.
Так же может быть проблема с индексами.
Еще стоит обратить внимание, что MySQL обладает скудным функционалом и не дает администратору базы такие инструменты как vacuum или cluster.
Возможно, если Вы перейдете на PostgreSQL и настроите vacuum, то производительность увеличится в десятки раз. А если модель данных позволяет сделать cluster столбец в PostgreSQL, то этот запрос будет обрабатываться еще быстрее.
Если же нет возможности поменять базу, а данные упираются именно в MySQL, а не сеть, то посмотрите форки MySQL. Например, MariaDB. И уже на новой базе поэксперементируйте с типом таблиц (движок хранилища).
Стоит упомянуть о возможности прозрачного перехода с MySQL на MariaDB.
Keyup вне форума Ответить с цитированием
Старый 13.11.2015, 08:08   #7
ADSoft
Старожил
 
Регистрация: 25.02.2007
Сообщений: 4,150
По умолчанию

ну почему же, Партицирование есть в мускуле
http://habrahabr.ru/post/66151/
ADSoft вне форума Ответить с цитированием
Старый 13.11.2015, 13:30   #8
CodeNOT
Форумчанин
 
Аватар для CodeNOT
 
Регистрация: 08.11.2010
Сообщений: 593
По умолчанию

Цитата:
Сообщение от Keyup Посмотреть сообщение
Уйму времени - это больше одной секунды?
Запрос, который Вы показали очень легкий и 115гб не так уж много для него.
Если Вы хотите решить Вашу проблему, то найдите причину, почему Ваш запрос работает медленно.
Сейчас Ваш запрос может тормозить по причине забитости сети (LIMIT 1000 может долго передаваться по сети).
Вы не указали тип таблиц. В MySQL есть несколько типов таблиц и некоторые из них делают блокировки.
Так же может быть проблема с индексами.
Еще стоит обратить внимание, что MySQL обладает скудным функционалом и не дает администратору базы такие инструменты как vacuum или cluster.
Возможно, если Вы перейдете на PostgreSQL и настроите vacuum, то производительность увеличится в десятки раз. А если модель данных позволяет сделать cluster столбец в PostgreSQL, то этот запрос будет обрабатываться еще быстрее.
Если же нет возможности поменять базу, а данные упираются именно в MySQL, а не сеть, то посмотрите форки MySQL. Например, MariaDB. И уже на новой базе поэксперементируйте с типом таблиц (движок хранилища).
Стоит упомянуть о возможности прозрачного перехода с MySQL на MariaDB.
там innodb, блокировок нет.
на PostgreSQL переезд будет позднее, сейчас как раз и стоит mariadb

тут я предполагаю что как раз проблемы вызваны производительностью самой фс, по-этому и решил разбить на несколько таблицы
CodeNOT вне форума Ответить с цитированием
Старый 13.11.2015, 13:30   #9
CodeNOT
Форумчанин
 
Аватар для CodeNOT
 
Регистрация: 08.11.2010
Сообщений: 593
По умолчанию

Цитата:
Сообщение от ADSoft Посмотреть сообщение
ну почему же, Партицирование есть в мускуле
http://habrahabr.ru/post/66151/
спасибо, я видимо точно не правильно дал опеределение, Партиционирование как раз то что нужно, как сделаю напишу мануал и наверное выложу тесты если кому-то будет интересно
CodeNOT вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск