Спасибо,
заточено не только на торговую, но начиналось все с нее в разных вариантах, да
задачи действительно для поставил-делегировал-исполнил, ну и как напоминальщик. цепочки документов создаются в документах, а задачи уже утилитарная вещь.
сейчас обсуждаем необходимость комментариев к задачам и их иерархичность, но пока никому из наших партнеров это не нужно.
Так что есть и цепочки документов, и передача между стадиями, и контроль исполнения(оплат к примеру) и дедлайны можно ставить по документам, и статусы документов меняются автоматически, ну и аналитика как раз строится в большей части по всей цепочке документов, а не только по одному виду
Большое спасибо.
Согласен, вообще странно в наш век держать БД компании на локальных решениях, когда уже термин облако — устарел.
Очевидные направления нашего развития — больше аналитики, поддержка производств и тех. процессов, система электронного оборота документов (уже есть в зачаточном виде для малых предприятий с правами доступа).
Пока что готовых велосипедов за 10 лет в тех сферах, где мы внедрялись не обнаружено. Все велосипеды выглядят как колеса от Oracle, рама от Microsoft, руль open-source и все это не работает, или стоит космических денег.
Люди часто по 5-6 лет ищут варианты, пытаются сделать сами или заплатить любые деньги — только сделайте — вот список требований. Пока что эффективно этот вопросы для наших клиентов закрыли мы. Ни в коем случае не говорю, что других вариантов нет — скорее всего есть, но сейчас для наших партнеров мы решаем этот вопрос и делаем свою работу.
Согласен про сильную сторону — законодательство, наши сильные стороны: удобство, мобильность, неограниченность по всем параметрам, быстродействие.
Касательно скорости — к примеру, аналитические отчеты мы выкатываем клиенту часто за 15 минут после запроса. Естественно если они универсальны, то появляются и у других клиентов автоматом. Сколько займет у стандартного решения разработка аналитики? Каковы шансы пользоваться им клиенту из другого города, у которого 1С внедрен другим агрегатором? Цена вопроса?
Также прибавим цену железа, его настройки, обслуживающего персонала…
Спасибо
Пока мы берем на обслуживание только крупные фирмы, с заключением договора и нашей гарантией. Дело в том, что для них выгоднее отдать эту тему на аутсорсинг хотя бы по причине компетентности и полного спектра услуг, про цену молчу.
Может быть когда-то и дойдет время до open-source модели, но сейчас мы обслуживаем систему и держим базы данных у нас, внедряем любые отчеты по запросу клиента в течение суток, импортируем данные из других источников и многое другое, что требует некоторого контроля версий.
Коробочные версии также не решают проблем клиентов целиком, а делать гибкую сборку с гарантией — большая работа.
спасибо. по количеству и качеству комментариев к предыдущим статьям подумал что можно все подсократить… буду стараться более развернуто. но про индекс и про БД которая его хранит я писал раньше.
у меня нет цели написать мануал как сделать свой поисковик построчно, я рассказываю про решения в узких местах, а пересказать 7 лет разработки, экспериментов, и тд и тп нереально
конечно хочется, только вот вопрос скорости не встает если все сделано правильно — с диска 1 seek 1 read для выдачи результатов. в статье про БД я расписал несколько подходов которые я использую
а в ОЗУ оно не влезет, и это описано в первой статье цикла — примерный размер даже небольшого индекса измеряется десятками гигабайт. у меня 10 млн страниц, 50 гб без текстов только индекс.
вот тут я рассказываю про AVL дерево которое решает вопросы быстро и просто habrahabr.ru/blogs/search_engines/123951/
там кстати и другие альтернативы в коментах предлагают.
а сейчас хеш, например по словам в БД, у меня устроен именно так как вы описываете.
хотя — если ваша реализация решает все вопросы, то какая разница будет это B,RB,Heap или любое другое дерево
может это я такой криворукий что моя реализация самого оптимального дерева будет хуже одной самого не оптимального, но которую у меня получилось реализовать случайно — хорошо
короче зависит от конкретных задач — у меня хорошо работает AVL
RB на больших примерах тормознее. splay затрудняюсь оценить. вы прикиньте затраты на построение и на поиск по нему не N*1000 записей, а N*1000000 — порядок другой
одна из причин почему стандартные СУБД под таблицами в миллионы записей ложатся (к примеру mysql) — потому что там для индексов часто используют B дерево с ограниченной высотой, и в листьях слишком много записей получается
это будет дальше, вообще сам по себе PR это учитывает в своей формуле — не думаю что отдельно надо вводить сильные коэффициенты. может быть пару фильтров или метрик — да как один из небольших вкладов в решающую формулу
Но, мне кажется, невнимательно прочитали список операций которые надо выполнять и постановку задачи в первой статье цикла…
Не видел ни одной СУБД в состоянии быстро считывать последовательно пару миллиардов записей. Да и таблицы которые бы весили десятки гигабайт и легко обрабатывались тоже редко встретишь в СУБД
Самые частые операции — выборка по ID, и считывание таблицы целиком последовательно. Исходя из этого списки страниц — худшая реализация т.к. надо сначала найти нужную позицию на диске для выборки, в случае же считывания подряд беготня по страницам весьма надоест. В моем случае имеет место жесткая буфферизация чтения, чего в случае с расположенными в непонятном порядке страницами не сделать.
Ну и главное достоинство самописной БД — всегда известно как должно быть устроено приложение чтобы использовать возможности БД на 100% а не на 10%, что я и делаю повсеместно
у меня на машинах от 4Gb памяти, может конечно если поставить 32 то и можно положить хотя бы индексы все в память, но все равно же вырастет. У меня удвоение происходит за месяц активной работы.
да, все индексы у меня тоже в отдельных таблицах. А памяти не хватает — кеш базы слов сам по себе от 100 до 200 mb, я уж не говорю про Url. Следующая статья будет про то как я их храню
заточено не только на торговую, но начиналось все с нее в разных вариантах, да
задачи действительно для поставил-делегировал-исполнил, ну и как напоминальщик. цепочки документов создаются в документах, а задачи уже утилитарная вещь.
сейчас обсуждаем необходимость комментариев к задачам и их иерархичность, но пока никому из наших партнеров это не нужно.
Так что есть и цепочки документов, и передача между стадиями, и контроль исполнения(оплат к примеру) и дедлайны можно ставить по документам, и статусы документов меняются автоматически, ну и аналитика как раз строится в большей части по всей цепочке документов, а не только по одному виду
Согласен, вообще странно в наш век держать БД компании на локальных решениях, когда уже термин облако — устарел.
Очевидные направления нашего развития — больше аналитики, поддержка производств и тех. процессов, система электронного оборота документов (уже есть в зачаточном виде для малых предприятий с правами доступа).
Люди часто по 5-6 лет ищут варианты, пытаются сделать сами или заплатить любые деньги — только сделайте — вот список требований. Пока что эффективно этот вопросы для наших клиентов закрыли мы. Ни в коем случае не говорю, что других вариантов нет — скорее всего есть, но сейчас для наших партнеров мы решаем этот вопрос и делаем свою работу.
Согласен про сильную сторону — законодательство, наши сильные стороны: удобство, мобильность, неограниченность по всем параметрам, быстродействие.
Касательно скорости — к примеру, аналитические отчеты мы выкатываем клиенту часто за 15 минут после запроса. Естественно если они универсальны, то появляются и у других клиентов автоматом. Сколько займет у стандартного решения разработка аналитики? Каковы шансы пользоваться им клиенту из другого города, у которого 1С внедрен другим агрегатором? Цена вопроса?
Также прибавим цену железа, его настройки, обслуживающего персонала…
Пока мы берем на обслуживание только крупные фирмы, с заключением договора и нашей гарантией. Дело в том, что для них выгоднее отдать эту тему на аутсорсинг хотя бы по причине компетентности и полного спектра услуг, про цену молчу.
Может быть когда-то и дойдет время до open-source модели, но сейчас мы обслуживаем систему и держим базы данных у нас, внедряем любые отчеты по запросу клиента в течение суток, импортируем данные из других источников и многое другое, что требует некоторого контроля версий.
Коробочные версии также не решают проблем клиентов целиком, а делать гибкую сборку с гарантией — большая работа.
у меня нет цели написать мануал как сделать свой поисковик построчно, я рассказываю про решения в узких местах, а пересказать 7 лет разработки, экспериментов, и тд и тп нереально
а в ОЗУ оно не влезет, и это описано в первой статье цикла — примерный размер даже небольшого индекса измеряется десятками гигабайт. у меня 10 млн страниц, 50 гб без текстов только индекс.
habrahabr.ru/blogs/search_engines/123951/
там кстати и другие альтернативы в коментах предлагают.
а сейчас хеш, например по словам в БД, у меня устроен именно так как вы описываете.
может это я такой криворукий что моя реализация самого оптимального дерева будет хуже одной самого не оптимального, но которую у меня получилось реализовать случайно — хорошо
короче зависит от конкретных задач — у меня хорошо работает AVL
одна из причин почему стандартные СУБД под таблицами в миллионы записей ложатся (к примеру mysql) — потому что там для индексов часто используют B дерево с ограниченной высотой, и в листьях слишком много записей получается
Но, мне кажется, невнимательно прочитали список операций которые надо выполнять и постановку задачи в первой статье цикла…
Не видел ни одной СУБД в состоянии быстро считывать последовательно пару миллиардов записей. Да и таблицы которые бы весили десятки гигабайт и легко обрабатывались тоже редко встретишь в СУБД
Самые частые операции — выборка по ID, и считывание таблицы целиком последовательно. Исходя из этого списки страниц — худшая реализация т.к. надо сначала найти нужную позицию на диске для выборки, в случае же считывания подряд беготня по страницам весьма надоест. В моем случае имеет место жесткая буфферизация чтения, чего в случае с расположенными в непонятном порядке страницами не сделать.
Ну и главное достоинство самописной БД — всегда известно как должно быть устроено приложение чтобы использовать возможности БД на 100% а не на 10%, что я и делаю повсеместно