распечатал статью про Splay деревья. я о них никогда даже не слышал, а штука оказывается интересная. можно было бы по-больше расписать )
B, B+ деревьев нет (( Очень хотелось бы увидеть сводную таблицу по деревьям со сложностями основных операций и рекомендациям по тому, в каких областях применять.
Кстати, если уж рассматривать именно в плане практического применения, а не реализации — есть возможность сделать подборку открытых библиотек, в которых те или иные деревья реализованы? получилась бы просто отменная подборка по тематике.
а вот интересно, присудствуют ли у вас какие-либо отличия при подсчёте убытков от нереализованного товара от подсчёта убытков от пиратсва в софте, например? потому что схемы подсчёта убытков от пиратства я просто в принципе не понимаю: если я поставил пиратскую копию фотошопа — совсем не факт, что я готов купить лицензию. может я вместо этого поставлю бесплатный гимп, и мне его вполне хватит.
или же расчет убытков идет больше на интуитивном уровне?
1. а вот это уточнение уже довольно интересно. так как я не вращаюсь в этой сфере на несимметричность графика я не обратил никакого внимания. а можно тогда подробнее объяснить, с чем она связана?
По сабжу — график, конечно, интересный. но, по-моему, это довольно очевидно. Было бы интересно послушать непосредственно про алгоритмы и методики вычисления этих матриц и прогнозов.
и еще, если есть возможность — не могли бы Вы рассказать про алгоритмы, на основе которых выбранные товары располагаются рядом.
На сколько я себе представляю этот вопрос, это должен быть некий алгоритм, балансирующий между двумя гранями:
* расположение рядом в первую очередь родственных товаров (все сорта печенья в одном месте)
* с другой стороны — как можно более близкое расположение товаров, которые наиболее часто вместе покупаются.
как вариант — переиндексировать на другой машине. или можно делать на той же машине (если ресурсов хватает), но в другой файл индекса. потом копировать индекс в нужное место/перезапускать демона.
у меня вроде бы такая схема работает. не уверен, на сколько это грамотно с точки зрения философии сфинкса.
интересует возможность задания списка синонимов? хотя бы однословных.
например, хочется, чтобы starcraft, старкрафт, старик — воспринимались как одно и то же. то есть на запрос со словом старкрафт находились документы со starcraft
на сколько я понял, в конфиге можно указать файл т.н. исключений, но вроде бы это не совсем то.
есть ли существующие средства для подобных вкусностей или нет? предвидятся? в какое место кода смотреть, чтобы (возможно) написать патч?
это гораздо более сложная задача, относящаяся к аналитике и логическому выводу. Мне кажется, в ближайшие лет пять-десять сделать подобную систему вряд ли удастся.
А вот давать точные ответы, а не ссылки, на факты, типа «когда родился текущий президент россии», «какие фильмы сняты режиссерами, родившимися с 1950 по 1060 года» или же «где купить раскладушки нокиа с блютусом, камерой до 10000» — вполне реально. именно в этом направлении мы и стараемся двигаться, разрабатывая систему ответов на фактографические запросы
хранить статистику в memcache, на мой взгляд, не очень правильно. перезагрузка сервера — и все теряется.
у нас примерно по такому же принципу работает система логирования/статистики. раз в промежуток времени запускается скрипт полного обсчета статистики или же просто обновления новыми данными. Статистика записывается в отдельные таблицы: по дням/месяцам/годам. то есть у вас есть огромная таблица с полными данными (я думаю, что лучше одна — легче будет обрабатывать и добавлять новые котировки. а от объема 20 миллонов записей в год с мускулем ничего не случится). и есть ее проекции на нужные вам периоды интервалы времени.
мемкэш в этой схеме имеет смысл использовать между таблицами конечной статистики и пользователем, исключительно для кэширования запросов на выборку больших массивов данных (например, все данные по какой-либо котировке за год). вот их стоит помещать в мемкэш, чтобы лишний раз базу не дергать.
кстати, здесь имеет смысл подумать над тем, какую СУБД выбрать. Учитывая специфику ваших запросов, возможно стоит подумать над тем, чтобы для базы с полной статистикой по котировкам использовать постгрес, а для сокращенной статистики — мускуль. это позволит избежать лишних блокировок, которые могут возникнуть во время того, как с одной стороны будет запущен скрипт обновления статистики, а с другой стороны, будут добавляться новые данные. Если постгрес не вариант — то по крайней мере потестировать Ваши запросы и нагрузки на InnoDB и MyISAM в мускуле.
1) меня необходимость заставила пересесть на постгрес. вот список причин, по которым меня мускуль не смог удовлетворить в принципе, так что как альтернатива он даже не рассматривался:
* работа с varchar. Объем таблиц — миллионы строк, join по текстовому ключу от varchar(500) вешает базу напрочь. Связано это с тем, что при всяких join, order by и т.п. происходит создание временной таблицы в памяти, а она не работает с варчарами — только с char фиксированной длины. Поэтому память улетает очень быстро. Оперативки не хватает — он выгружает все данные в файл, причем не сразу, а порциями. И эти порции сортирует. Время выполнения одного тестового запроса — около 8 часов. Оптимизировать больше не удалось. С другой стороны постгрес абсолютно на тех же самых данных отработал запрос за пол часа. Плюс к этому:
** в постгресе не надо задавать длину варчара и длину ключа — он сам это все автоматически определяет и подстраивается
** гораздо легче выполняются все операции над текстовыми столбцами
** есть возможность задавать индексы по функциям. поначалу это непривычно, однако может существенно упростить жизнь в некоторых случаях
* второй момент связан с таким понятием, как схема, которого в мускуле просто нет. Очень удобная штука
* ну и последнее (что отмечали) — большие объемы данных. По моему опыту работы, в постгресе с этим как-то проще обстоит.
2) сложности при переходе для меня были всего две. это установка/настройка пользователей и путаница понятий в схеме/базе, так как в мускуле и постгресе они немного различаются (например, в мускуле можно делать запросы между несколькими базами, в постгресе — нельзя, для этого есть более удобная вещь — схемы)
После первичного ознакомления лучше всего, если попробуете написать более-менее объемный проект (хотя бы в несколько тысяч строк), придерживаясь объектной реализации. Не обязательно сайт, это может быть консолькое приложение
Или же можно взять какой-нибудь фреймворк, типа Symphony, Zend, CakePHP, и разобраться в его структуре. Они все объектные, так что будете учиться на реальных примерах. Из перечисленных трех мне больше нравится Zend, но конкретно Вам лучше взять то, что знает наиболее досягаемый для Вас гуру.
а так — классная штука, только пока там народу мало. сидит 4 человека, три на шарпе, один на джаве
B, B+ деревьев нет (( Очень хотелось бы увидеть сводную таблицу по деревьям со сложностями основных операций и рекомендациям по тому, в каких областях применять.
Кстати, если уж рассматривать именно в плане практического применения, а не реализации — есть возможность сделать подборку открытых библиотек, в которых те или иные деревья реализованы? получилась бы просто отменная подборка по тематике.
а по сабжу: преподавать — это здорово и интересно) главное, чтобы палки в колёса при этом не ставили в виде «сдачи нормативов по знанию M$ Paint»
или же расчет убытков идет больше на интуитивном уровне?
2. спасибо, буду ждать
и еще, если есть возможность — не могли бы Вы рассказать про алгоритмы, на основе которых выбранные товары располагаются рядом.
На сколько я себе представляю этот вопрос, это должен быть некий алгоритм, балансирующий между двумя гранями:
* расположение рядом в первую очередь родственных товаров (все сорта печенья в одном месте)
* с другой стороны — как можно более близкое расположение товаров, которые наиболее часто вместе покупаются.
Применяются ли алгоритмы кластеризации типа CLOPE ( www.basegroup.ru/library/analysis/clusterization/clope/ ), или же это какие-то специфические алгоритмы?
у меня вроде бы такая схема работает. не уверен, на сколько это грамотно с точки зрения философии сфинкса.
shodan?
например, хочется, чтобы starcraft, старкрафт, старик — воспринимались как одно и то же. то есть на запрос со словом старкрафт находились документы со starcraft
на сколько я понял, в конфиге можно указать файл т.н. исключений, но вроде бы это не совсем то.
есть ли существующие средства для подобных вкусностей или нет? предвидятся? в какое место кода смотреть, чтобы (возможно) написать патч?
А вот давать точные ответы, а не ссылки, на факты, типа «когда родился текущий президент россии», «какие фильмы сняты режиссерами, родившимися с 1950 по 1060 года» или же «где купить раскладушки нокиа с блютусом, камерой до 10000» — вполне реально. именно в этом направлении мы и стараемся двигаться, разрабатывая систему ответов на фактографические запросы
у нас примерно по такому же принципу работает система логирования/статистики. раз в промежуток времени запускается скрипт полного обсчета статистики или же просто обновления новыми данными. Статистика записывается в отдельные таблицы: по дням/месяцам/годам. то есть у вас есть огромная таблица с полными данными (я думаю, что лучше одна — легче будет обрабатывать и добавлять новые котировки. а от объема 20 миллонов записей в год с мускулем ничего не случится). и есть ее проекции на нужные вам периоды интервалы времени.
мемкэш в этой схеме имеет смысл использовать между таблицами конечной статистики и пользователем, исключительно для кэширования запросов на выборку больших массивов данных (например, все данные по какой-либо котировке за год). вот их стоит помещать в мемкэш, чтобы лишний раз базу не дергать.
кстати, здесь имеет смысл подумать над тем, какую СУБД выбрать. Учитывая специфику ваших запросов, возможно стоит подумать над тем, чтобы для базы с полной статистикой по котировкам использовать постгрес, а для сокращенной статистики — мускуль. это позволит избежать лишних блокировок, которые могут возникнуть во время того, как с одной стороны будет запущен скрипт обновления статистики, а с другой стороны, будут добавляться новые данные. Если постгрес не вариант — то по крайней мере потестировать Ваши запросы и нагрузки на InnoDB и MyISAM в мускуле.
* работа с varchar. Объем таблиц — миллионы строк, join по текстовому ключу от varchar(500) вешает базу напрочь. Связано это с тем, что при всяких join, order by и т.п. происходит создание временной таблицы в памяти, а она не работает с варчарами — только с char фиксированной длины. Поэтому память улетает очень быстро. Оперативки не хватает — он выгружает все данные в файл, причем не сразу, а порциями. И эти порции сортирует. Время выполнения одного тестового запроса — около 8 часов. Оптимизировать больше не удалось. С другой стороны постгрес абсолютно на тех же самых данных отработал запрос за пол часа. Плюс к этому:
** в постгресе не надо задавать длину варчара и длину ключа — он сам это все автоматически определяет и подстраивается
** гораздо легче выполняются все операции над текстовыми столбцами
** есть возможность задавать индексы по функциям. поначалу это непривычно, однако может существенно упростить жизнь в некоторых случаях
* второй момент связан с таким понятием, как схема, которого в мускуле просто нет. Очень удобная штука
* ну и последнее (что отмечали) — большие объемы данных. По моему опыту работы, в постгресе с этим как-то проще обстоит.
2) сложности при переходе для меня были всего две. это установка/настройка пользователей и путаница понятий в схеме/базе, так как в мускуле и постгресе они немного различаются (например, в мускуле можно делать запросы между несколькими базами, в постгресе — нельзя, для этого есть более удобная вещь — схемы)
Для философии советую почитать паттерны проектирования:
* agiledev
* Вики: Паттерны проектирования
После первичного ознакомления лучше всего, если попробуете написать более-менее объемный проект (хотя бы в несколько тысяч строк), придерживаясь объектной реализации. Не обязательно сайт, это может быть консолькое приложение
Или же можно взять какой-нибудь фреймворк, типа Symphony, Zend, CakePHP, и разобраться в его структуре. Они все объектные, так что будете учиться на реальных примерах. Из перечисленных трех мне больше нравится Zend, но конкретно Вам лучше взять то, что знает наиболее досягаемый для Вас гуру.
одна поправка — при смене темы линейка с выбором темы всегда сбрасывается на начало, что есть не очень удобно.