1 таблица VS несколько
1 таблица VS несколько
Сам собаку съел на высокообъемных таблицах, но блин не могу решить как правильнее поступить в данной ситуации... к сути:
Есть таблица(ы) суммарный объем ~600-900К записей.
Скрипт, не сложной регуляркой, заранее может определить в какой из трех таблиц обращаться. То есть ситуации искать и тут и там и еще вот там не будет.
В пиковые моменты запросы вида «findByPk» могут достигать несколько сотен в секунду.
Вопросы:
Насколько целесообразно разделить таблицы на 3 по 200-300К?
AR для нескольких таблиц, есть красивое решение или плодить модели? DAO?
PS:
Я понимаю что разделение даст прирост производительности, но насколько он будет существенным?
Есть таблица(ы) суммарный объем ~600-900К записей.
Скрипт, не сложной регуляркой, заранее может определить в какой из трех таблиц обращаться. То есть ситуации искать и тут и там и еще вот там не будет.
В пиковые моменты запросы вида «findByPk» могут достигать несколько сотен в секунду.
Вопросы:
Насколько целесообразно разделить таблицы на 3 по 200-300К?
AR для нескольких таблиц, есть красивое решение или плодить модели? DAO?
PS:
Я понимаю что разделение даст прирост производительности, но насколько он будет существенным?
Re: 1 таблица VS несколько
Я думаю что вам нужно думать о кэшировании и выборе поискового движка нежели заниматься этим + прочесть немного документации о СУБД.Arnowt писал(а):PS:
Я понимаю что разделение даст прирост производительности, но насколько он будет существенным?
И больше не кушайте собак )
Re: 1 таблица VS несколько
Думать или не думать о кэшировании - не об том вопрос, это отдельная история даст повышение производительности в лучшем случае на 5-10%.solo писал(а):Я думаю что вам нужно думать о кэшировании и выборе поискового движка нежели заниматься этим + прочесть немного документации о СУБД.Arnowt писал(а):PS:
Я понимаю что разделение даст прирост производительности, но насколько он будет существенным?
И больше не кушайте собак )
Что касается документации есть место где описано подобное?
Везде пишут примерно следующее: один поиск в большой таблице быстрее чем три поиска в маленьких - но это к моей ситуации не имеет отношения.
А то что поиск в маленькой таблице быстрее чем большой уже очевидно.
Так что либо вы не читали мой пост, либо плиз ссылку на документацию где вышеуказанное опровергается.
Последний раз редактировалось Arnowt 2013.11.04, 06:50, всего редактировалось 1 раз.
Re: 1 таблица VS несколько
Что касается поискового движка, то считаю свой выбор оптимальным.
Уверен ничего быстрее чем поиск по «PRIMARY» в СУБД быть не может.
Уверен ничего быстрее чем поиск по «PRIMARY» в СУБД быть не может.
Re: 1 таблица VS несколько
Можно поинтересоваться какой движок выбрали вы? И скиньте структуру таблицы.
5-10% это цифра из воздуха. Чтобы писать такое нужно делать реальные замеры.
А таблицы бьют в случае когда выносят их на другие железки.
5-10% это цифра из воздуха. Чтобы писать такое нужно делать реальные замеры.
А таблицы бьют в случае когда выносят их на другие железки.
Re: 1 таблица VS несколько
Ну да цифра из воздуха, потому и разброс такой.
Движок полностью самописный и основан на опубликованном* алгоритме от яндекса.
структура очень простая:
word - varchar(30)
pr - varchar(4000)
frequency - int(10) unsigned
pr рассчитывается путем индексирования, этим занимаются отдельные фоновые процессы (он постоянно меняется это одна из причин почему кэш будет мало эффективен, еще нужно учитывать огромный разброс слов(я тут перепроверил их примерно 1,5M), можно попытаться делать мини таблицу в которой вести стату по наиболее запрашиваемым словам, но это опять же дробление + доп нагрузка, в общем кэш я не отвергаю, но повторю это отдельная история).
Задача простая найти ключи в word и извлечь многомерные массивы из pr.
потом уже складывая матрицы pr вычислить наиболее релевантные id из другой таблицы, вот эти данные уже конечно кэшируются.
Но когда я говорил о сотнях запросов я имел ввиду что запросы будут разные.
*понятно что это не то что они реально используют, но меня он устраивает. Релевантность по моему мнению великолепная.
Движок полностью самописный и основан на опубликованном* алгоритме от яндекса.
структура очень простая:
word - varchar(30)
pr - varchar(4000)
frequency - int(10) unsigned
pr рассчитывается путем индексирования, этим занимаются отдельные фоновые процессы (он постоянно меняется это одна из причин почему кэш будет мало эффективен, еще нужно учитывать огромный разброс слов(я тут перепроверил их примерно 1,5M), можно попытаться делать мини таблицу в которой вести стату по наиболее запрашиваемым словам, но это опять же дробление + доп нагрузка, в общем кэш я не отвергаю, но повторю это отдельная история).
Задача простая найти ключи в word и извлечь многомерные массивы из pr.
потом уже складывая матрицы pr вычислить наиболее релевантные id из другой таблицы, вот эти данные уже конечно кэшируются.
Но когда я говорил о сотнях запросов я имел ввиду что запросы будут разные.
*понятно что это не то что они реально используют, но меня он устраивает. Релевантность по моему мнению великолепная.
Re: 1 таблица VS несколько
Вы писали свой движок СУБД? Sphinx не пробовали? Но судя по pr - varchar(4000) Вам не в обиду нужно почитать о типах данных.
Re: 1 таблица VS несколько
>>>выборе поискового движка
Поисковый движок - свой
СУБД - MySQL
Sphinx - работает с леммами? (интересует русский и английский)
>>Но судя по pr - varchar(4000) Вам не в обиду нужно почитать о типах данных.
Ну как сказать... нужно проверить на самом деле, поле text насколько я знаю это отдельный файл. не факт что будет быстрее.
Поисковый движок - свой
СУБД - MySQL
Sphinx - работает с леммами? (интересует русский и английский)
>>Но судя по pr - varchar(4000) Вам не в обиду нужно почитать о типах данных.
Ну как сказать... нужно проверить на самом деле, поле text насколько я знаю это отдельный файл. не факт что будет быстрее.
Последний раз редактировалось Arnowt 2013.11.04, 12:28, всего редактировалось 2 раза.
Re: 1 таблица VS несколько
Ну если вы уверенны что text отдельный файл и будет медленнее. Тогда почему таблица будет быстрее работать когда ее разбить?Arnowt писал(а):>>>выборе поискового движка
Поисковый движок - свой
СУБД - MySQL
Sphinx - работает с леммами? (интересует русский и английский)
>>Но судя по pr - varchar(4000) Вам не в обиду нужно почитать о типах данных.
Ну как сказать... нужно проверить на самом деле, поле text насколько я знаю это отдельный файл. не факт что будет быстрее.
Re: 1 таблица VS несколько
Когда спрашивал о "поисковом движке" я имел введу InnoDB или MyISAM
Re: 1 таблица VS несколько
>>Тогда почему таблица будет быстрее работать когда ее разбить?
1 три таблицы не миллионы
2 поиск по большей таблице будет дольше
3 я буду осуществлять только 1 поиск, на не три в каждой таблице. Тут только вопрос какой выигрыш если 0,001 сек то конечно нет смысла дробить, а если 0,1 то безусловно нужно.
Но чтобы проверить нужно пару суток на индексацию, а потом еще столько же на переиндексацию.
Собственно процесс запущен, тк готового ответа похоже что нет.
>>Когда спрашивал о "поисковом движке" я имел введу InnoDB
InnoDB хотя блокировками не пользуюсь.
1 три таблицы не миллионы
2 поиск по большей таблице будет дольше
3 я буду осуществлять только 1 поиск, на не три в каждой таблице. Тут только вопрос какой выигрыш если 0,001 сек то конечно нет смысла дробить, а если 0,1 то безусловно нужно.
Но чтобы проверить нужно пару суток на индексацию, а потом еще столько же на переиндексацию.
Собственно процесс запущен, тк готового ответа похоже что нет.
>>Когда спрашивал о "поисковом движке" я имел введу InnoDB
InnoDB хотя блокировками не пользуюсь.
Re: 1 таблица VS несколько
Ну тогда есть смысл первое что сделать переконвертировать в MyISAMArnowt писал(а):InnoDB хотя блокировками не пользуюсь.
Re: 1 таблица VS несколько
аргументы?
insert update в случае MyISAM блокируют всю таблицу. InnoDB запись.
Я конечно уже давненько читал доки, что-то изменилось? или у меня в голове что-то перепуталось?
insert update в случае MyISAM блокируют всю таблицу. InnoDB запись.
Я конечно уже давненько читал доки, что-то изменилось? или у меня в голове что-то перепуталось?
Re: 1 таблица VS несколько
select быстрее в MyISAM
Re: 1 таблица VS несколько
да... чет мне не понятно почему MySQL подталкивает всех к innoDB
Сейчас сделал тестовый заплыв на insert и update 1К индексных текстов... разница в 1,5 в пользу MyISAM
Нужно конечно еще тестировать insert, update, select, но предварительные результаты таковы.
Сейчас сделал тестовый заплыв на insert и update 1К индексных текстов... разница в 1,5 в пользу MyISAM
Нужно конечно еще тестировать insert, update, select, но предварительные результаты таковы.
Re: 1 таблица VS несколько
вы же инсерт по очереди делаете, т.е. не попадаете в блокировки
Re: 1 таблица VS несколько
Ну да, да, я ж потому и сказал что нужно еще тестировать с "insert, update, select" Естественно в параллельном режиме.
Re: 1 таблица VS несколько
Arnowt писал(а):InnoDB хотя блокировками не пользуюсь.
Re: 1 таблица VS несколько
http://sphinxsearch.com/docs/2.1.1/conf-morphology.htmlSphinx - работает с леммами? (интересует русский и английский)
Re: 1 таблица VS несколько
Угу, спасибо уже видел, нужно разбираться как его пользовать вообще и в рамках конкретной задачи в частности.Nafania писал(а):http://sphinxsearch.com/docs/2.1.1/conf-morphology.htmlSphinx - работает с леммами? (интересует русский и английский)
Потестирую пиковую производительность в сравнении, когда будет все готово(свой метод VS sphinx).