Всем привет! Есть категории в виде дерева и каждой категории принадлежат
товары. Интересно услышать архитектуры решений подобного, именно под
высокие нагрузки. Мб какие паттерны, тип таблиц, база и т.д
Возникает проблемы есть выводить все товары во всех ветках какой то
определенной ветки. И если писать типа такого
SELECT .. FROM tovar WHERE categories_id IN (....) с перечислением всех
возможных категорий. Получается слишком много id категорий, нужен другой
подход. Спасибо!

IN в качестве запроса оптимальное решение в данном случае. Лучше не
будет. Конечно ключи на categories_id должны быть.
Highload здесь никакого нет. Решение банальное - кеширование.

17.08.2012 3:21, Николай Измайлов пишет:
> Всем привет! Есть категории в виде дерева и каждой категории
> принадлежат товары. Интересно услышать архитектуры решений подобного,
> именно под высокие нагрузки. Мб какие паттерны, тип таблиц, база и т.д
> Возникает проблемы есть выводить все товары во всех ветках какой то
> определенной ветки. И если писать типа такого
> SELECT .. FROM tovar WHERE categories_id IN (....) с перечислением
> всех возможных категорий. Получается слишком много id категорий,
> нужен другой подход. Спасибо!

17.08.2012 06:21, Николай Измайлов пишет:
> Всем привет! Есть категории в виде дерева и каждой категории
> принадлежат товары. Интересно услышать архитектуры решений подобного,
> именно под высокие нагрузки. Мб какие паттерны, тип таблиц, база и т.д
> Возникает проблемы есть выводить все товары во всех ветках какой то
> определенной ветки. И если писать типа такого
> SELECT .. FROM tovar WHERE categories_id IN (....) с перечислением
> всех возможных категорий. Получается слишком много id категорий,
> нужен другой подход. Спасибо!
Можно использовать sphinx, при генерации индексов сетать в товарах
список категорий которым он принадлежит и потом sql_attr_multi на поле в
котором хранятся категории.

(1) google: nested-tree
(2) Nafania дебил
(3) научись вопросы формулировать
(4) пожалуйста

Это почему еще?

17.08.2012 13:18, the.silly.sad@gmail.com пишет:
> (1) google: nested-tree
> (2) Nafania дебил
> (3) научись вопросы формулировать
> (4) пожалуйста
>

Let's the war begin!

17 августа 2012 г., 20:52 пользователь Nafania <nafania293@gmail.com>написал:

> Это почему еще?
>
> 17.08.2012 13:18, the.silly.sad@gmail.com пишет:
>
> (1) google: nested-tree
>> (2) Nafania дебил
>> (3) научись вопросы формулировать
>> (4) пожалуйста
>>
>>
>
>

Ну ещё подеритесь, девочки


17.08.2012 15:35, Anatoly Pashin написал:
> Let's the war begin!
>
> 17 августа 2012 г., 20:52 пользователь Nafania <nafania293@gmail.com
> <mailto:nafania293@gmail.com>> написал:
>
> Это почему еще?
>
> 17.08.2012 13:18, the.silly.sad@gmail.com
> <mailto:the.silly.sad@gmail.com> пишет:
>
> (1) google: nested-tree
> (2) Nafania дебил
> (3) научись вопросы формулировать
> (4) пожалуйста
>
>
>
>

Да скучно тут, почему бы и нет :)

17.08.2012 16:12, Sergey S. Golovashov пишет:
>
> Ну ещё подеритесь, девочки
>
>
> 17.08.2012 15:35, Anatoly Pashin написал:
>> Let's the war begin!
>>
>> 17 августа 2012 г., 20:52 пользователь Nafania <nafania293@gmail.com
>> <mailto:nafania293@gmail.com>> написал:
>>
>> Это почему еще?
>>
>> 17.08.2012 13:18, the.silly.sad@gmail.com
>> <mailto:the.silly.sad@gmail.com> пишет:
>>
>> (1) google: nested-tree
>> (2) Nafania дебил
>> (3) научись вопросы формулировать
>> (4) пожалуйста
>>
>>
>>
>>
>

Раз скучно - вопрос. В списке процессов на каждый php-fpm уходит по
9-10% cpu. Но иногда кратковременно вылезают одиночные по 40-50. Как
узнать что вызывается в этот момент и чем занят php? В ответ
достаточно пары названий программ - дальше разберусь. Заранее спасибо
и всем удачных выходных.

17 августа 2012 г., 16:18 пользователь Nafania <nafania293@gmail.com> написал:
> Да скучно тут, почему бы и нет :)
>
> 17.08.2012 16:12, Sergey S. Golovashov пишет:
>
>
> Ну ещё подеритесь, девочки
>
>
> 17.08.2012 15:35, Anatoly Pashin написал:
>
> Let's the war begin!
>
> 17 августа 2012 г., 20:52 пользователь Nafania <nafania293@gmail.com>
> написал:
>>
>> Это почему еще?
>>
>> 17.08.2012 13:18, the.silly.sad@gmail.com пишет:
>>
>>> (1) google: nested-tree
>>> (2) Nafania дебил
>>> (3) научись вопросы формулировать
>>> (4) пожалуйста
>>>
>>
>>
>
>
>
>



--
С уважением,
Антипов Илья

Прошу прощения. Забыл:
PHP 5.3.10 (cli) (built: Mar 28 2012 22:44:06)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v1.3.2, Copyright (c) 2005-2011, by mOo

Linux version 3.0.0-12-server (buildd@crested) (gcc version 4.6.1
(Ubuntu/Linaro 4.6.1-9ubuntu3) ) #20-Ubuntu SMP Fri Oct 7 16:36:30 UTC
2011


17 августа 2012 г., 16:34 пользователь Илья Антипов
<ilantipov@gmail.com> написал:
> Раз скучно - вопрос. В списке процессов на каждый php-fpm уходит по
> 9-10% cpu. Но иногда кратковременно вылезают одиночные по 40-50. Как
> узнать что вызывается в этот момент и чем занят php? В ответ
> достаточно пары названий программ - дальше разберусь. Заранее спасибо
> и всем удачных выходных.
>
> 17 августа 2012 г., 16:18 пользователь Nafania <nafania293@gmail.com> написал:
>> Да скучно тут, почему бы и нет :)
>>
>> 17.08.2012 16:12, Sergey S. Golovashov пишет:
>>
>>
>> Ну ещё подеритесь, девочки
>>
>>
>> 17.08.2012 15:35, Anatoly Pashin написал:
>>
>> Let's the war begin!
>>
>> 17 августа 2012 г., 20:52 пользователь Nafania <nafania293@gmail.com>
>> написал:
>>>
>>> Это почему еще?
>>>
>>> 17.08.2012 13:18, the.silly.sad@gmail.com пишет:
>>>
>>>> (1) google: nested-tree
>>>> (2) Nafania дебил
>>>> (3) научись вопросы формулировать
>>>> (4) пожалуйста
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
> --
> С уважением,
> Антипов Илья



--
С уважением,
Антипов Илья

правильнее "Nested sets"


2012/8/17 the.silly.sad@gmail.com <the.silly.sad@gmail.com>

> (1) google: nested-tree
> (2) Nafania дебил
> (3) научись вопросы формулировать
> (4) пожалуйста
>

Materialized Path в принципе больше подходит под такие задачи, но не так
удобно индексировать по текстовому полю, подходит и Nested Set, но в нём
неудобно изменять дерево.
Если категории меняются нечасто, то можно использовать NS для категорий, а
у продуктов хранить помимо id категории ещё left и right, соответственно
обновляя их при изменении таковых в таблице категорий.

Если я правильно понял суть проблемы, то можно pinba поставить и смотреть
кекие скрипты едят cpu, а потом используя таймеры определить проблемное
место в коде. Это если явно нельзя отпрофайлить.
17.08.2012 15:34 пользователь "Илья Антипов" <ilantipov@gmail.com> написал:

> Раз скучно - вопрос. В списке процессов на каждый php-fpm уходит по
> 9-10% cpu. Но иногда кратковременно вылезают одиночные по 40-50. Как
> узнать что вызывается в этот момент и чем занят php? В ответ
> достаточно пары названий программ - дальше разберусь. Заранее спасибо
> и всем удачных выходных.
>
> 17 августа 2012 г., 16:18 пользователь Nafania <nafania293@gmail.com>
> написал:
> > Да скучно тут, почему бы и нет :)
> >
> > 17.08.2012 16:12, Sergey S. Golovashov пишет:
> >
> >
> > Ну ещё подеритесь, девочки
> >
> >
> > 17.08.2012 15:35, Anatoly Pashin написал:
> >
> > Let's the war begin!
> >
> > 17 августа 2012 г., 20:52 пользователь Nafania <nafania293@gmail.com>
> > написал:
> >>
> >> Это почему еще?
> >>
> >> 17.08.2012 13:18, the.silly.sad@gmail.com пишет:
> >>
> >>> (1) google: nested-tree
> >>> (2) Nafania дебил
> >>> (3) научись вопросы формулировать
> >>> (4) пожалуйста
> >>>
> >>
> >>
> >
> >
> >
> >
>
>
>
> --
> С уважением,
> Антипов Илья
>

Не хватает еще совета использовать графоориентированные бд.
17.08.2012 14:35 пользователь "Anatoly Pashin" <b1rdexadm@gmail.com>
написал:

> Let's the war begin!
>
> 17 августа 2012 г., 20:52 пользователь Nafania <nafania293@gmail.com>написал:
>
>> Это почему еще?
>>
>> 17.08.2012 13:18, the.silly.sad@gmail.com пишет:
>>
>> (1) google: nested-tree
>>> (2) Nafania дебил
>>> (3) научись вопросы формулировать
>>> (4) пожалуйста
>>>
>>>
>>
>>
>

17 августа 2012 г., 16:34 пользователь Илья Антипов
<ilantipov@gmail.com> написал:
> Раз скучно - вопрос. В списке процессов на каждый php-fpm уходит по
> 9-10% cpu. Но иногда кратковременно вылезают одиночные по 40-50. Как
> узнать что вызывается в этот момент и чем занят php? В ответ
> достаточно пары названий программ - дальше разберусь. Заранее спасибо
> и всем удачных выходных.

Xdebug, pinba

Все ниженаписанное предполагает субд MySQL.
Категорически против IN :) Предельно медленные запросы получаются, при несчастливом стечении обстоятельств выполняется на порядок медленнее чем пачка SELECT ... FROM tovar WHERE categories_id=?
В зависимости от частоты правок, их характера и типов выборок может пригодиться одна из имплементаций деревьев на рсубд. С предварительным выбором может помочь статья http://demiurg.livejournal.com/53125.html (старая, картинки уже канули в лету, но общую картину показывает нормально).
Ну и как подсказали выше - кеширование, без него любое дерево "ляжет" при сколько-нибудь ощутимой нагрузке.
По типам таблицы - поиграйтесь с разными движками (innodb/aria/xtradb.)


On Aug 17, 2012, at 10:50, Nafania wrote:

> IN в качестве запроса оптимальное решение в данном случае. Лучше не будет. Конечно ключи на categories_id должны быть.
> Highload здесь никакого нет. Решение банальное - кеширование.
>
> 17.08.2012 3:21, Николай Измайлов пишет:
>> Всем привет! Есть категории в виде дерева и каждой категории принадлежат товары. Интересно услышать архитектуры решений подобного, именно под высокие нагрузки. Мб какие паттерны, тип таблиц, база и т.д
>> Возникает проблемы есть выводить все товары во всех ветках какой то определенной ветки. И если писать типа такого
>> SELECT .. FROM tovar WHERE categories_id IN (....) с перечислением всех возможных категорий. Получается слишком много id категорий, нужен другой подход. Спасибо!
>
>

17 августа 2012 г., 3:21 пользователь Николай Измайлов
<nekulin123@gmail.com> написал:
> Всем привет! Есть категории в виде дерева и каждой категории принадлежат
> товары. Интересно услышать архитектуры решений подобного, именно под высокие
> нагрузки. Мб какие паттерны, тип таблиц, база и т.д
> Возникает проблемы есть выводить все товары во всех ветках какой то
> определенной ветки. И если писать типа такого
> SELECT .. FROM tovar WHERE categories_id IN (....) с перечислением всех
> возможных категорий. Получается слишком много id категорий, нужен другой
> подход. Спасибо!

На Хабре была статья сравнения методов хранения древовидных структур
[1] - рекомендую ее прочитать

1- http://habrahabr.ru/post/47280/

Смотря какого размера пачка. С обстоятельствами такими еще ни разу не
сталкивался.
Касательно деревьев. Деревья это хорошо и удобно. Однако они порождают
порой такие sql запросы, что запрос с IN будет просто цветочками.
Поэтому повторюсь - кешируем все и везде.
Кешируем результаты выборки из базы и обновляем кеш при изменении
структуры (а она в устоявшемся проекте меняется не часто).
Кешируем страницы в хтмл нгинксом, если не критична актуальность страницы.
итд итп.
Кеш наше все.


17.08.2012 12:18, Alexander Bodnarashik пишет:
> Все ниженаписанное предполагает субд MySQL.
> Категорически против IN :) Предельно медленные запросы получаются, при
> несчастливом стечении обстоятельств выполняется на порядок медленнее
> чем пачка SELECT ... FROM tovar WHERE categories_id=?
> В зависимости от частоты правок, их характера и типов выборок может
> пригодиться одна из имплементаций деревьев на рсубд. С предварительным
> выбором может помочь статья
> http://demiurg.livejournal.com/53125.html (старая, картинки уже канули
> в лету, но общую картину показывает нормально).
> Ну и как подсказали выше - кеширование, без него любое дерево "ляжет"
> при сколько-нибудь ощутимой нагрузке.
> По типам таблицы - поиграйтесь с разными движками (innodb/aria/xtradb.)
>
>
> On Aug 17, 2012, at 10:50, Nafania wrote:
>
>> IN в качестве запроса оптимальное решение в данном случае. Лучше не
>> будет. Конечно ключи на categories_id должны быть.
>> Highload здесь никакого нет. Решение банальное - кеширование.
>>
>> 17.08.2012 3:21, Николай Измайлов пишет:
>>> Всем привет! Есть категории в виде дерева и каждой категории
>>> принадлежат товары. Интересно услышать архитектуры решений
>>> подобного, именно под высокие нагрузки. Мб какие паттерны, тип
>>> таблиц, база и т.д
>>> Возникает проблемы есть выводить все товары во всех ветках какой то
>>> определенной ветки. И если писать типа такого
>>> SELECT .. FROM tovar WHERE categories_id IN (....) с перечислением
>>> всех возможных категорий. Получается слишком много id категорий,
>>> нужен другой подход. Спасибо!
>>
>>
>

Не хочу втягиваться в "дискуссию", поэтому постараюсь кратко: все (большинство) известных подходов к построению деревьев в рсубд имеют свои слабые и сильные стороны и хотя бы в одном случае (удаление, вставка, изменение) имеют запрос не хуже, чем вариант с IN (поскольку IN тоже вполне себе подход для оперирования частями деревьев), это если строго. Если на бытовом уровне - в среднем по больнице вариант с IN отстой.
И кеш никак не спасает от задержек при первоначальной выборке (для чтения) и совсем не помогает при любых изменениях в ветках/узлах дерева.

On Aug 17, 2012, at 16:31, Nafania wrote:

> Смотря какого размера пачка. С обстоятельствами такими еще ни разу не сталкивался.
> Касательно деревьев. Деревья это хорошо и удобно. Однако они порождают порой такие sql запросы, что запрос с IN будет просто цветочками.
> Поэтому повторюсь - кешируем все и везде.
> Кешируем результаты выборки из базы и обновляем кеш при изменении структуры (а она в устоявшемся проекте меняется не часто).
> Кешируем страницы в хтмл нгинксом, если не критична актуальность страницы.
> итд итп.
> Кеш наше все.
>
>
> 17.08.2012 12:18, Alexander Bodnarashik пишет:
>> Все ниженаписанное предполагает субд MySQL.
>> Категорически против IN :) Предельно медленные запросы получаются, при несчастливом стечении обстоятельств выполняется на порядок медленнее чем пачка SELECT ... FROM tovar WHERE categories_id=?
>> В зависимости от частоты правок, их характера и типов выборок может пригодиться одна из имплементаций деревьев на рсубд. С предварительным выбором может помочь статья http://demiurg.livejournal.com/53125.html (старая, картинки уже канули в лету, но общую картину показывает нормально).
>> Ну и как подсказали выше - кеширование, без него любое дерево "ляжет" при сколько-нибудь ощутимой нагрузке.
>> По типам таблицы - поиграйтесь с разными движками (innodb/aria/xtradb.)
>>
>>
>> On Aug 17, 2012, at 10:50, Nafania wrote:
>>
>>> IN в качестве запроса оптимальное решение в данном случае. Лучше не будет. Конечно ключи на categories_id должны быть.
>>> Highload здесь никакого нет. Решение банальное - кеширование.
>>>
>>> 17.08.2012 3:21, Николай Измайлов пишет:
>>>> Всем привет! Есть категории в виде дерева и каждой категории принадлежат товары. Интересно услышать архитектуры решений подобного, именно под высокие нагрузки. Мб какие паттерны, тип таблиц, база и т.д
>>>> Возникает проблемы есть выводить все товары во всех ветках какой то определенной ветки. И если писать типа такого
>>>> SELECT .. FROM tovar WHERE categories_id IN (....) с перечислением всех возможных категорий. Получается слишком много id категорий, нужен другой подход. Спасибо!
>>>
>>>
>>
>
>

Почему IN такие плохие? Есть какие-нибудь статьи на эту тему?
В целях самообразования хотелось бы узнать.

17.08.2012 17:58, Alexander Bodnarashik пишет:
> Не хочу втягиваться в "дискуссию", поэтому постараюсь кратко: все (большинство) известных подходов к построению деревьев в рсубд имеют свои слабые и сильные стороны и хотя бы в одном случае (удаление, вставка, изменение) имеют запрос не хуже, чем вариант с IN (поскольку IN тоже вполне себе подход для оперирования частями деревьев), это если строго. Если на бытовом уровне - в среднем по больнице вариант с IN отстой.
> И кеш никак не спасает от задержек при первоначальной выборке (для чтения) и совсем не помогает при любых изменениях в ветках/узлах дерева.
>
> On Aug 17, 2012, at 16:31, Nafania wrote:
>
>> Смотря какого размера пачка. С обстоятельствами такими еще ни разу не сталкивался.
>> Касательно деревьев. Деревья это хорошо и удобно. Однако они порождают порой такие sql запросы, что запрос с IN будет просто цветочками.
>> Поэтому повторюсь - кешируем все и везде.
>> Кешируем результаты выборки из базы и обновляем кеш при изменении структуры (а она в устоявшемся проекте меняется не часто).
>> Кешируем страницы в хтмл нгинксом, если не критична актуальность страницы.
>> итд итп.
>> Кеш наше все.
>>
>>
>> 17.08.2012 12:18, Alexander Bodnarashik пишет:
>>> Все ниженаписанное предполагает субд MySQL.
>>> Категорически против IN :) Предельно медленные запросы получаются, при несчастливом стечении обстоятельств выполняется на порядок медленнее чем пачка SELECT ... FROM tovar WHERE categories_id=?
>>> В зависимости от частоты правок, их характера и типов выборок может пригодиться одна из имплементаций деревьев на рсубд. С предварительным выбором может помочь статья http://demiurg.livejournal.com/53125.html (старая, картинки уже канули в лету, но общую картину показывает нормально).
>>> Ну и как подсказали выше - кеширование, без него любое дерево "ляжет" при сколько-нибудь ощутимой нагрузке.
>>> По типам таблицы - поиграйтесь с разными движками (innodb/aria/xtradb.)
>>>
>>>
>>> On Aug 17, 2012, at 10:50, Nafania wrote:
>>>
>>>> IN в качестве запроса оптимальное решение в данном случае. Лучше не будет. Конечно ключи на categories_id должны быть.
>>>> Highload здесь никакого нет. Решение банальное - кеширование.
>>>>
>>>> 17.08.2012 3:21, Николай Измайлов пишет:
>>>>> Всем привет! Есть категории в виде дерева и каждой категории принадлежат товары. Интересно услышать архитектуры решений подобного, именно под высокие нагрузки. Мб какие паттерны, тип таблиц, база и т.д
>>>>> Возникает проблемы есть выводить все товары во всех ветках какой то определенной ветки. И если писать типа такого
>>>>> SELECT .. FROM tovar WHERE categories_id IN (....) с перечислением всех возможных категорий. Получается слишком много id категорий, нужен другой подход. Спасибо!
>>>>
>>

На продакшене никто ничего не отлаживает, для этого есть тестовые среды.
On Aug 18, 2012 3:12 AM, "Alex Samorukov" <samm@os2.kiev.ua> wrote:

> On 08/17/2012 05:51 AM, Aleksandr Sytar wrote:
>
>> 17 августа 2012 г., 16:34 пользователь Илья Антипов
>> <ilantipov@gmail.com> написал:
>>
>>> Раз скучно - вопрос. В списке процессов на каждый php-fpm уходит по
>>> 9-10% cpu. Но иногда кратковременно вылезают одиночные по 40-50. Как
>>> узнать что вызывается в этот момент и чем занят php? В ответ
>>> достаточно пары названий программ - дальше разберусь. Заранее спасибо
>>> и всем удачных выходных.
>>>
>> Xdebug, pinba
>>
> xdebug - идиотский совет, на продакшне убьет весь перформанс. Пинба - ну
> может быть, но лог - куда проще включить. Такие дела.
>

On 08/17/2012 05:51 AM, Aleksandr Sytar wrote:
> 17 августа 2012 г., 16:34 пользователь Илья Антипов
> <ilantipov@gmail.com> написал:
>> Раз скучно - вопрос. В списке процессов на каждый php-fpm уходит по
>> 9-10% cpu. Но иногда кратковременно вылезают одиночные по 40-50. Как
>> узнать что вызывается в этот момент и чем занят php? В ответ
>> достаточно пары названий программ - дальше разберусь. Заранее спасибо
>> и всем удачных выходных.
> Xdebug, pinba
xdebug - идиотский совет, на продакшне убьет весь перформанс. Пинба - ну
может быть, но лог - куда проще включить. Такие дела.

Именно потому совет и идиотский - на тестовой среде выловить это будет
куда сложнее + адский оверхед xdebug не позволит это сделать, скорее всего.

On 08/18/2012 10:17 PM, Aleksandr Sytar wrote:
>
> На продакшене никто ничего не отлаживает, для этого есть тестовые среды.
>
> On Aug 18, 2012 3:12 AM, "Alex Samorukov" <samm@os2.kiev.ua
> <mailto:samm@os2.kiev.ua>> wrote:
>
> On 08/17/2012 05:51 AM, Aleksandr Sytar wrote:
>
> 17 августа 2012 г., 16:34 пользователь Илья Антипов
> <ilantipov@gmail.com <mailto:ilantipov@gmail.com>> написал:
>
> Раз скучно - вопрос. В списке процессов на каждый php-fpm
> уходит по
> 9-10% cpu. Но иногда кратковременно вылезают одиночные по
> 40-50. Как
> узнать что вызывается в этот момент и чем занят php? В ответ
> достаточно пары названий программ - дальше разберусь.
> Заранее спасибо
> и всем удачных выходных.
>
> Xdebug, pinba
>
> xdebug - идиотский совет, на продакшне убьет весь перформанс.
> Пинба - ну может быть, но лог - куда проще включить. Такие дела.
>