Структура таблиц

[crautcher]

спросил сперва на другом форуме , там мне ниче так никто и не ответил :

нужно сделать таблицы для сервиса поиска синонимов , слов будет много , как лучше организовать таблицы чтобы слова не повторялись и можно было легко выбрать связку синонимов для введенного слова ?

[s0rr0w]

Да быстро join будет работать, быстро. Нужно очень быстрое решение - берите сфинкс, скармливайте ему статьи с синонимами и ищите.

А то, что предлагает s0rr0w - это на пустом месте родить сотни мегабайт ненужных, дублированных данных ради неопределенной экономии.

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

Предлагаю провести эксперимент и доказать, что JOIN будет всего на 20% менее эффективным при решении данной задачи. Количество данных - миллион строк.

[MiksIr]

Да блин. Для того, что бы думать о докупках серверов нужно хотя бы один купить и убить его. Не нужно тут сферических коней гонять. Если уж у вас голова от прочтения всяких "архитектур" съехала - сфинкс будет эффективнее вашего "сторажда". Основное правило разработки хайлоад архитектур не "кешируй все что можно", а ищи узкие места и ищи решение как их ускорить. Это может быть кеш, а может быть другое хранилище или другой алгоритм. Сейчас слушать о каких-то 20-50-100% просто смешно. Для начала придумайте мне такой сервис, у которого проверка синонимов будет насколько узким местом, что ее нужно оптимизировать, потом доведите посещаемость до таких величин, а потом уже думайте. А до тех пор нет никакого оправдания, что вы вместо часа потратили два дня на создания и проверку системы актуализации кеша (а если она при этом еще работает как приложение, а не как триггеры в базе - то написание документации что как запускать), который реально нужен этому проекту как машине 5-е колесо.

[s0rr0w]

Если уж у вас голова от прочтения всяких "архитектур" съехала - сфинкс будет эффективнее вашего "сторажда".

Эффективнее по каким параметрам? Как вы вообще эффективность посчитали?

Основное правило разработки хайлоад архитектур не "кешируй все что можно", а ищи узкие места и ищи решение как их ускорить.

Т.е. бесконечно переделывай архитектуру? Бугагашеньки. Хайлоад архитектура - это фикция. Она просто имеет возможность масштабироваться либо горизонтально, либо вертикально.

Для начала придумайте мне такой сервис, у которого проверка синонимов будет насколько узким местом, что ее нужно оптимизировать, потом доведите посещаемость до таких величин, а потом уже думайте.

Легко. Контент-анализ

А до тех пор нет никакого оправдания, что вы вместо часа потратили два дня на создания и проверку системы актуализации кеша (а если она при этом еще работает как приложение, а не как триггеры в базе - то написание документации что как запускать), который реально нужен этому проекту как машине 5-е колесо.

Если вы не понимаете прелесть решения, то это не значит, что его там нет. Если брать решение задачи только на уровне БД, то да, мой вариант похож на 5-е колесо. Но если провести полный цикл действий над данными, и доставить их потребителю, то тут суммарный код станет гораздо проще, потому что серверная сторона будет работать в качестве "прокси" по прямой передаче данных из базы клиенту. Кто готовит эти данные - пофиг, взял из базы, выплюнул в stdout, и забыл. А подготовка данных к выдаче будет абсолютно автономна и не зависеть от местоположения данных, таблиц, количества обрабатывающего кода. Обновляй в оффлайне себе и радуйся.

[MiksIr]

> Эффективнее по каким параметрам? Как вы вообще эффективность посчитали?

По тем же самым, что вы посчитали эффективность запихивания 100500 данных в таблицу.

> Легко. Контент-анализ

Зачем для контент-анализа синонимы? Или вы про генерацию сеошных говнотекстов? И что, там большине нагрузки? Лол.

> Т.е. бесконечно переделывай архитектуру? Бугагашеньки. Хайлоад архитектура - это фикция. Она просто имеет возможность масштабироваться либо горизонтально, либо вертикально.

Не только. Спорить с вами смысла не вижу. У меня только одна спроектированная с нуля архитектура, все остальное мелкие подкладки падающих под рекламщиками проектов, может спроектировав десятки я как вы обрету такое же видение, что нет никакой архитектуры.

Пока же у меня другое мнение, и я делаю ровно то, что необходимо, ибо есть стоимость часа работы программистов, есть стоимость обслуживания, есть вероятность возникновения человеческой ошибки при том или ином решении и ее стоимость. Вот ваше решение - очень дорогое. Примера, когда в данном конкретном случае это окупится - не вижу. Равно как и причины при таких адских нагрузках, о которых вы рассказываете, хранить этот кеш в базе, а не выкладывать в файловую систему.

А вообще, советую почитать, как работает поиск по индексу, как работают джойны, куда лезет база для выковыривания text полей и т.п.

А так же на что тратится время в обычной реляционной базе.

Ну и попробовать эти ваши запросы. У меня нет базы в миллион слов, есть в 2 тысячи - выборка по слову и джойн показывают одинаковое время. Ну, я понимаю почему, только опять спорить? А то передете сейчас с редисам всяким... бедный топикстартер. Спросил как сделать примтивную вещь, а ему целую архитектуру под высокую нагрузку в ответ

Edited May 17, 2012 by MiksIr

[s0rr0w]

По тем же самым, что вы посчитали эффективность запихивания 100500 данных в таблицу.

У меня все как раз хорошо считается простой математикой. Даже если денормализация будет занимать в 100 раз больше времени, чем разница между джойн и неджойн реализацией, то я это время легко отобью со временем.

Зачем для контент-анализа синонимы? Или вы про генерацию сеошных говнотекстов? И что, там большине нагрузки? Лол.

Затем, что они участвуют в поиске наиболее релевантных текстов. Без них можно, но падает качество обработки.

Не только. Спорить с вами смысла не вижу. У меня только одна спроектированная с нуля архитектура, все остальное мелкие подкладки падающих под рекламщиками проектов, может спроектировав десятки я как вы обрету такое же видение, что нет никакой архитектуры.

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

Со временем придет понимание, что решения "в лоб" или "как привык" обходятся очень дорого. Особенно в тех случаях, когда исходные данные занимают сотни гигабайт.

Вот ваше решение - очень дорогое. Примера, когда в данном конкретном случае это окупится - не вижу. Равно как и причины при таких адских нагрузках, о которых вы рассказываете, хранить этот кеш в базе, а не выкладывать в файловую систему.

Экспорт в файловую систему - еще дороже обойдется.

Я давно уже практикую правило, что лучше день потерять, но потом за 5 минут долететь. Стоимость программного продукта не равна стоимости первичной разработки, а включает в себя еще и стоимость модификаций в дальнейшем. Так вот, чем дешевле производить модификации - тем выгоднее получается. Выполнение этого требования вынуждает применять более дорогостоящие решения в начале, но они с лихвой окупаются в конце.

А вообще, советую почитать, как работает поиск по индексу, как работают джойны, куда лезет база для выковыривания text полей и т.п.

Зачем? В разных DB эти принципы идентичны, но очень сильно отличаются в реализации. И это накладывает свои ограничения.

У меня нет базы в миллион слов, есть в 2 тысячи

Это не интересно. На таком объеме все легко умещается в памяти. Нет ни дискового IO, ни накладных расходов самой базы. На таком объеме денормализация будет действительно дорогостоящим решением.

Спросил как сделать примтивную вещь, а ему целую архитектуру под высокую нагрузку в ответ

Его вопрос был вполне четким Структура таблиц для быстрого поиска слов

Так как объемы данных не были определены, то логично предположить, что их будет ровно столько, сколько и слов в нескольких языках. И узнать больше о проблемах - это гораздо интереснее, чем получить только один SQL-запрос.

[MiksIr]

Я все же не верю, что вы что-то серьезное создавали уже сами. Претендуя на знания хайлоада выкидывать такие вещи, как SQL парсер и планировщик, из-за которого вы даже 20% прироста между этими двумя запросами можете не получить, ибо сама выборка быстра по сравнению с накладными запросами. Или говорить что-то про "дорогой экспорт в фаловую систему" (интересно с чего бы это), забывая, что файлы можно отдавать напрямую веб-сервером и даже минуя userspace, за счет чего можно обслуживать огромное число запросов.

А вот это

Стоимость программного продукта не равна стоимости первичной разработки, а включает в себя еще и стоимость модификаций в дальнейшем. Так вот, чем дешевле производить модификации - тем выгоднее получается. Выполнение этого требования вынуждает применять более дорогостоящие решения в начале, но они с лихвой окупаются в конце.

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

Спасибо, посмеялся тут

Со временем придет понимание, что решения "в лоб" или "как привык" обходятся очень дорого. Особенно в тех случаях, когда исходные данные занимают сотни гигабайт.

отличное решение "не в лоб" - сделать из сотен гигабайт десятки теробайт ради нопределенных целей "что бы было круто". Т.е. вы уже выбросили по штуке баксов за каждый теробайт ради непонятно чего, что бы хранить кучу дополнительных данных, которые, может, никогда и не будут востребованы. Отличная архитектура, чего уж =)))

[s0rr0w]

Я все же не верю, что вы что-то серьезное создавали уже сами. Претендуя на знания хайлоада выкидывать такие вещи, как SQL парсер и планировщик, из-за которого вы даже 20% прироста между этими двумя запросами можете не получить, ибо сама выборка быстра по сравнению с накладными запросами.

У меня есть стойкое ощущение, что вы спорите сами с собой, вернее со своими фантазиями.

Или говорить что-то про "дорогой экспорт в фаловую систему" (интересно с чего бы это), забывая, что файлы можно отдавать напрямую веб-сервером и даже минуя userspace, за счет чего можно обслуживать огромное число запросов.

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

А вот это вообще детский сад. Начиная с того, что более сложный код сложнее модифицировать и обслуживать.

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

1. Коннектимся к базе

2. Запрашиваем строку с нужным словом из матвьюхи или кэш-таблицы

3. Делаем эхо json-а.

Сравниваем с "классическим" вариантом

1. Коннектимся к базе

2. Запрашиваем перечень синонимов

3. Из этого перечня в цикле склеиваем json

4. Выплевываем json

Что делаем, если поменялся формат json-a?

1й способ. Ничего

2й способ. Переписываем запрос и конкатенатор json-а (90% кода!!!)

Да, в первом способе все равно приходится делать изменения, но уже в другом месте.

Какие плюсы первого подхода?

+ не требуется повторное тестирование данного участка кода при изменениях форматов данных

+ не требует обновления кода на продакшин-системе, меняются только данные

+ тупейший код, который имеет предсказуемую скорость выполнения при любых условиях

отличное решение "не в лоб" - сделать из сотен гигабайт десятки теробайт ради нопределенных целей "что бы было круто". Т.е. вы уже выбросили по штуке баксов за каждый теробайт ради непонятно чего, что бы хранить кучу дополнительных данных, которые, может, никогда и не будут востребованы. Отличная архитектура, чего уж =)))

Посчитайте, что дешевле, купить новый сервер за 10килобаксов, или на 1к винтов докупить? Миллион записей не будет занимать террабайты, это будет гигабайт 100 максимум. Не размеры для текущих накопителей.

Кстати, советую почитать про методику XP, тогда мои высказывания не будут вызывать приступы беспричинного смеха

Кстати, тестирование скорости различных запросов

http://www.andrewrollins.com/2009/06/21/mysql-join-performance/

[MiksIr]

Я все же не верю, что вы что-то серьезное создавали уже сами. Претендуя на знания хайлоада выкидывать такие вещи, как SQL парсер и планировщик, из-за которого вы даже 20% прироста между этими двумя запросами можете не получить, ибо сама выборка быстра по сравнению с накладными запросами.

У меня есть стойкое ощущение, что вы спорите сами с собой, вернее со своими фантазиями.

Ясно, т.е. все же вы не очень в курсе. Почитайте про HandlerSocket. И насколько увеличивается время выборки. Вот эта "дельта" и есть затраты на SQL парсер. Если парсер и все накладные отрабатывают 5 мс, выборка по ключу 1мс, а джойн.. пусть 3 мс, сколько процентов будет? Это был вам легкий намек, что без noSQL ваше решение смысла не имеет.

Или говорить что-то про "дорогой экспорт в фаловую систему" (интересно с чего бы это), забывая, что файлы можно отдавать напрямую веб-сервером и даже минуя userspace, за счет чего можно обслуживать огромное число запросов.

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

Лолчто? Речь идет о хранении кеша в ФС. Какое тут индексирование, какой парсер запросов... о чем вы. Вы что, статический кеш никогда не делали? В память ваша база не влезет, забудьте.

1. Коннектимся к базе

2. Запрашиваем строку с нужным словом из матвьюхи или кэш-таблицы

3. Делаем эхо json-а.

Сравниваем с "классическим" вариантом

1. Коннектимся к базе

2. Запрашиваем перечень синонимов

3. Из этого перечня в цикле склеиваем json

4. Выплевываем json

Что делаем, если поменялся формат json-a?

1й способ. Ничего

2й способ. Переписываем запрос и конкатенатор json-а (90% кода!!!)

1й способ - переписываем генератор кеша или запрос во вьюхе, сбрасываем весь кеш, перегенерируем весь кеш. Причем в огромной транзакции, так как нам после обновления кеша на новый формат нужно очень быстро переключить на новую версию софта... ах, софт - это ajax на клиенте... ну извините, клиенты, которые в этот момент работают.

2-й способ - а запрос зачем переписывать? он делает ровно то, что нужно, т.е. достает данные, меняем только формат хранения, что бы генератор json сделал новую структуру.

В обоих случаях переписывается код. Большой вы фантазер, я погляжу.

Да, в первом способе все равно приходится делать изменения, но уже в другом месте.

Какие плюсы первого подхода?

+ не требуется повторное тестирование данного участка кода при изменениях форматов данных

+ не требует обновления кода на продакшин-системе, меняются только данные

+ тупейший код, который имеет предсказуемую скорость выполнения при любых условиях

- требует повторного тестирования другого участка, да и вообще тесты выполняются всегда перед деплоем

- требует код обновления на продакшн системе или что еще хуже, требует обновления вьюх

- тупейший джойн имеет предсказуемую скорость выполнения, в отличии от плавания вашего метода в моменты перегенерирования кеша, который меняет огромные объемы данных, а значит база выходит из стабильного прогнозированного режима.

Посчитайте, что дешевле, купить новый сервер за 10килобаксов, или на 1к винтов докупить? Миллион записей не будет занимать террабайты, это будет гигабайт 100 максимум. Не размеры для текущих накопителей.

Сами сказали - исходные данные сотни гигабайт. Ваша денормализация увеличит минимум раз в 10, не меньше, но запросто больше. Винты, к слову, тоже куда-то втыкать еще нужно.

Кстати, советую почитать про методику XP, тогда мои высказывания не будут вызывать приступы беспричинного смеха

Будут. Ни одни прием XP не подразумевает бацать год монстра в котором все заложено заранее под супер-пупер нагрузки, которые даже не в плане, а гипотетически выдуманы разработчиком. XP вообще не об этом, а то что и есть - нацелено на быстрый выпуск рабочего прототипа и плавное наращивание короткими итерациями.

Резюмируя: советую вам свои фантазии держать при себе. Идея кеширования стара как мир, но основная и очень важная идея, которая проходит через подавляющее большинство систем кеширования - система должна работать с отключенным кешем. С другими параметрами нагрузки, но работать должна. И самое главное - создается тогда, когда нужен. А не тогда, когда разработчику что-то спросонья почудится и он начнет создавать монстра оправдывая "а вдруг завтра 10 миллионов уников придет несмотря на то, что сейчас всего 15 человек". Но вы можете фантазировать дальше, только людям не советуйте или помечайте "когда вам одного сервера станет мало". Даже тогда такие советы вредны, ибо до конца не продуманы, но хоть "в тему" будет. На сим тему можно считать закрытой, устал уже спорить о конях в вакууме, предпочитаю более реальные проблемы решать.

Edited May 17, 2012 by MiksIr

[s0rr0w]

Ясно, т.е. все же вы не очень в курсе. Почитайте про HandlerSocket. И насколько увеличивается время выборки. Вот эта "дельта" и есть затраты на SQL парсер. Если парсер и все накладные отрабатывают 5 мс, выборка по ключу 1мс, а джойн.. пусть 3 мс, сколько процентов будет? Это был вам легкий намек, что без noSQL ваше решение смысла не имеет.

OMG, сделайте наконец себе базу с 1кк записями и проведите эксперимент. Все последние тесты, что я видел, не показывают многократного прироста скорости. Тот же MongoDB показывает результаты выборки хуже mySQL

Лолчто? Речь идет о хранении кеша в ФС. Какое тут индексирование, какой парсер запросов... о чем вы. Вы что, статический кеш никогда не делали? В память ваша база не влезет, забудьте.

Лолчто? Покажите мне этот файловый кэш, который работает без программной обвязки! Я хочу на это посмотреть!

1й способ - переписываем генератор кеша или запрос во вьюхе, сбрасываем весь кеш, перегенерируем весь кеш. Причем в огромной транзакции, так как нам после обновления кеша на новый формат нужно очень быстро переключить на новую версию софта... ах, софт - это ajax на клиенте... ну извините, клиенты, которые в этот момент работают.

Сбрасывать весь кэш зачем? И почему все должно быть именно в одной транзакции? И кто сказал, что пользователи должны получать изменения базы немедленно? Клиенты как работали, так и продолжают работать.

2-й способ - а запрос зачем переписывать? он делает ровно то, что нужно, т.е. достает данные, меняем только формат хранения, что бы генератор json сделал новую структуру.

Потенциально запрос тоже может изменяться из-за подключения дополнительных данных.

В обоих случаях переписывается код. Большой вы фантазер, я погляжу.

А я нигде не говорил, что он остается неизменным в моем случае. Он изменяется, но на другом уровне. Где фантазии? Может хватит наискось мои ответы читать?

- требует повторного тестирования другого участка, да и вообще тесты выполняются всегда перед деплоем

- требует код обновления на продакшн системе или что еще хуже, требует обновления вьюх

- тупейший джойн имеет предсказуемую скорость выполнения, в отличии от плавания вашего метода в моменты перегенерирования кеша, который меняет огромные объемы данных, а значит база выходит из стабильного прогнозированного режима.

1. Суть проверки другая. Смотрим на тестирование вашего кода. При любом чихе нужно делать

а) проверка подключения к базе

б) проверка возвращения запрашиваемых данных

в) проверка на правильность трансформации данных в json нужного формата

г) проверка на возврат данных

В моем случае пункты "а", "б" и "г" делаются единоразово, а проверка "в" делается независимо и уже несколько раз. Экономия времени колоссальная. Шансов на ошибку меньше, код проще. KISS в действии.

2. Вьюхи поменять так страшно?

3. Как уже было сказано неоднократно, кэш полностью будет обновлять только отважный.

Сами сказали - исходные данные сотни гигабайт. Ваша денормализация увеличит минимум раз в 10, не меньше, но запросто больше. Винты, к слову, тоже куда-то втыкать еще нужно.

Если вы про мой случай, то денормализация применяется в обязательном порядке, но в он-деманд режиме. Для задачи синонимов объем данных будет небольшой по современным меркам.

Будут. Ни одни прием XP не подразумевает бацать год монстра в котором все заложено заранее под супер-пупер нагрузки, которые даже не в плане, а гипотетически выдуманы разработчиком. XP вообще не об этом, а то что и есть - нацелено на быстрый выпуск рабочего прототипа и плавное наращивание короткими итерациями.

Вы невнимательно графики изучали

система должна работать с отключенным кешем. С другими параметрами нагрузки, но работать должна. И самое главное - создается тогда, когда нужен. А не тогда, когда разработчику что-то спросонья почудится и он начнет создавать монстра оправдывая "а вдруг завтра 10 миллионов уников придет несмотря на то, что сейчас всего 15 человек". Но вы можете фантазировать дальше, только людям не советуйте или помечайте "когда вам одного сервера станет мало". Даже тогда такие советы вредны, ибо до конца не продуманы, но хоть "в тему" будет. На сим тему можно считать закрытой, устал уже спорить о конях в вакууме, предпочитаю более реальные проблемы решать.

Денормализация данных в матвьюхи не являются кешем в том понимании, про которое идет речь в данном выражении. Во многих системах кэш является частью экосистемы, его отключение приводит к немедленному DoSу. Любой докладчик по хайлоаду не просто так повторяет одно и то же: "Кешируем все на всех уровнях". И я с ними абсолютно согласен.

Плох тот солдат, что не мечтает стать генералом. Плох тот программист, что решает задачу только от A до Z, а на все остальное смотрит с презрением, мол нам такого не задавали. Наша беседа дает стимул изучать больше, чем задавали. Да, наши мнения разнятся, но в споре рождается истина.

[s0rr0w]

Резюмирую.

Мой php-код выглядел бы примерно вот так

<?php
echo( DBM::getDataRow( "{ query: { from: 'table', items: ['json_string'], where: [ 'word = request' ] } }" )["json_string"] );
?>

Коннекшин к источнику данных переносим за пределы кода. Это позволит тестировать его один раз, а не при каждом вызове.

Язык SQL-запроса виртуализируем, чтобы не привязываться к синтаксису одной из реализаций SQL.

Если захочется поменять mySQL на тот же redis, приведенный код не будем трогать вообще, он будет работать при любых изменениях в способах хранения данных.

Денормализацию выносим в автономный процесс, может даже асинхронный.

Радуемся полученному результату.

А можно было бы все написать в одном файле, без кеширования, используя JOIN.