Думаю заметят, потому что может быть 200мс против 50

Да еще под нагрузкой

Вобщем я понял, нужно брать и проводить эксперимент на реальных данных

а может быть и пятнадцать

Вобщем я понял, нужно брать и проводить эксперимент на реальных данных

тут бы и сказать "наконец-то", да только и проводить его не надо

Почему?

потому что за всем этим не стоит ни реальной задачи, ни потребности, ни метрик

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

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

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

http://cdn.head-fi.org/b/b1/200x200px-ZC-b19413ed_aw-jeez.jpeg

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

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

ты пытаешься сэкономить на спичках

Зачем переводить задачу в плоскость "нет и на горизонте"? Моя задача, как инженера, спроектировать решени, рассчитать производительность под нагрузки, и выдать рабочее решение. Чтобы потом заказчик не звонил через год ночью в воскресенье с криками "у нас все упало".

А есть в помине или нет - меня не касается.

Зачем переводить задачу в плоскость "нет и на горизонте"? Моя задача, как инженера, спроектировать решени, рассчитать производительность под нагрузки, и выдать рабочее решение. Чтобы потом заказчик не звонил через год ночью в воскресенье с криками "у нас все упало".

давайте начнем с простого. какой здесь SLA? какие условия считаются приемлемыми?

Это могут быть заранее нагенеренные миллионы магазинчиков для виртуальной игры, и реалтаймовый поиск на лету. Минус решений sphinx и ES в том что это надо целую лишнюю сущность администрировать.

давайте начнем с простого. какой здесь SLA? какие условия считаются приемлемыми?

Меньше 99% думаю легко

меньше 99% что? меньше 99% аптайма приемлемо? как это связано со скоростью?

Это могут быть заранее нагенеренные миллионы магазинчиков для виртуальной игры, и реалтаймовый поиск на лету. Минус решений sphinx и ES в том что это надо целую лишнюю сущность администрировать.

вопрос шашечек и езды

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

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

и чтобы бесплатно, да.

давай все-таки к SLA и требованиям к задаче

момент с тем, как рассказывать заказчику про шашечки и езду осветит кто-нибудь другой

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

Я вот думаю что все же есть некий локальный максимум у этой функции от нескольких аргументов ;) И надо его найти.

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

Требования естественно могут поменяться, может эти интервалы буду разбиты еще на 5 каждый, кто ж его знает.

Если будет работать относительно медленно (>200мс) то пользователи будут расстраиваться.

Если надо будет очень мудрить с масштабированием/переиндексацией, то администраторы будут расстраиваться.

я никогда не гонял ни один движок на миллионах записей - ну, кроме того раза, когда не поверил этвуду, что у postgresql медленный count даже при indexscan - но с трудом представляю себе хранилище, которое будет давать 200 мс на десяти миллионах записей

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

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

Пару HP Proliant G10 на ссдшках последнего поколения + 256-512гб оперативной памяти. И всё будет ок.

Не сказать чтобы я прям сильно беспокоюсь об этом, но вопрос ящитаю абсолютно корректный и законный. И хорошо бы на него знать ответ, чтобы потом не было мучительно больно за потраченные миллионы.

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

Пару HP Proliant G10 на ссдшках последнего поколения + 256-512гб оперативной памяти. И всё будет ок.

потому что реплика должна быть вообще всегда

Пару HP Proliant G10 на ссдшках последнего поколения + 256-512гб оперативной памяти. И всё будет ок.

Спасибо это я увидел, приму к сведению.

потому что реплика должна быть вообще всегда

Ну должно быть еще приложение написано с поддержкой быстрого переключения с ES на реплику и обратно ;)

если не хотим тратить миллионы, вытряхиваем из заказчика sla, делаем тесты, берем с запасом

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

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

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

Ну да я конечно против того чтобы тащить отдельные поисковые движки в проект где можно и gist индексом обойтись

Прочитал всю вашу дисскуссию

Надеялся увидеть конкретику и какой то опыт, но ниасилил.

Я вынес только "вы экономите на спичках", "у вас нет таких задач", "вы спрашиваете не нужно"

ой закритиковали

А вот и нет :)

Но жаль что в гугле не нашлось статей про это

Фига кто-то денди любит

Нужно какое-то оборудование чтобы сделать такую наклейку?

Идешь в контору рекламную, где на виниле печатают, и все

Почитал и увидел себя 10 лет назад :-) надо быть готовым ко всему, нужно выбрать правильное решение, а вдруг нагрузка, да-да, такое уже было... И с другой стороны терпеливо поясняют, что для случая "а вдруг нагрузка" нужна оценка предела, под который считаются деньги: стоимость разработки, железа, сопровождения, простоя

Фига кто-то денди любит

https://www.google.ru/search?q=charles+severance+tattoo сразу вспомнил

Внезапно

кстати так ведь и не закончил https://www.coursera.org/learn/python-databases/home/welcome спасибо за напоминание )

Всё для тебя

День добрый! Недавно начал работать с postgresql 9.5. Помогите разобраться с настройками и оптимизации в postgresql. При Выполнение запроса: select * from "Documents" Total query runtime: 12.2 secs 57146 строк получено. В sql server ре он работает довольно шустро.. Может надо оптимизация в postgresql сделать или индексы создать. Заране спасибо всем.

День добрый! Недавно начал работать с postgresql 9.5. Помогите разобраться с настройками и оптимизации в postgresql. При Выполнение запроса: select * from "Documents" Total query runtime: 12.2 secs 57146 строк получено. В sql server ре он работает довольно шустро.. Может надо оптимизация в postgresql сделать или индексы создать. Заране спасибо всем.

Попробуйте mamonsu tune

https://github.com/postgrespro/mamonsu

сколько метрик оказывается в постгресе

Я установил mamonsu но всё равно результат тотже..

ERROR: S client not available

его надо не просто установить, а установить и запустить mamonsu tune, а после этого перезагрузиться

monitoring agent: mamonsu служба включена

monitoring agent.

это не tune. tune - это generic оптимизации навроде pgtune

его надо запускать отдельно

потому основное предназначение mamonsu - это сбор метрик. mamonsu tune - побочный продукт, mamonsu - как перочинный ножик для PostgreSQL

как knife для chef :)

https://wiki.postgresql.org/wiki/Slow_Query_Questions

его надо запускать отдельно

я новичок в этом деле только начал учить postgresql )) можете более подробно написать путь файла и как запустить его. Спасибо

https://wiki.postgresql.org/wiki/Slow_Query_Questions

для seq scan индексы нужны да </сарказм>

я новичок в этом деле только начал учить postgresql )) можете более подробно написать путь файла и как запустить его. Спасибо

запустить под рутом mamonsu tune и перезапустить postgresql

Почитал и увидел себя 10 лет назад :-) надо быть готовым ко всему, нужно выбрать правильное решение, а вдруг нагрузка, да-да, такое уже было... И с другой стороны терпеливо поясняют, что для случая "а вдруг нагрузка" нужна оценка предела, под который считаются деньги: стоимость разработки, железа, сопровождения, простоя

Эти оценки предела ничего не значат. Бизнес их берет с потолка.

плохой бизнес - да, с потолка

плохой бизнес - да, с потолка

Любой бизнес, который не сталкивался еще с такого рода задачей :)

это и есть пока ещё плохой бизнес

https://wiki.postgresql.org/wiki/Slow_Query_Questions

@Abdumutalovn https://www.youtube.com/watch?v=jGOkSerUPw4 - можно с этого начать

я был плохим исполнителем

Эти оценки предела ничего не значат. Бизнес их берет с потолка.

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

А не "хотим все, 100% аптайм и бесплатно"

> "делаем на чем умеем и смотрим возможности оптимизации". Так я этим и занимаюсь. Умеем в Pg/Mysql/Sphinx/ES. Надо найти лучшую комбинацию.

да я вчера заметил

его надо не просто установить, а установить и запустить mamonsu tune, а после этого перезагрузиться

Под виндой работает?

не еще вроде

лень было :)

А для windows как быть ))

блин как быть всё равно такая хрень.. Люди добрые помогите аа..))

не еще вроде

Ну мааам

заведи issue в github

:)

Оперативка: 4gb, Cpu: i3, винт: hdd. как ускорить этот процесс.. OC: windows 10 x64.