может 50ГБ? А то что-то вечером голова не варит и как-то простая арифметика не получается
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Структура сервиса SaaS: монолитный или распределенный
- Автор темы scorpion-ds
- Дата начала
может
5x10^10терабайты с 10^12 идут )
но в итоге за терабайт перешагнут легко с таким объёмом и тематикой.
WoLFiks
Не курю...
Опять Яндекс-Маркет?
При 500 надо конкретно о поддержке думать.
То одни что-нить поменяют в прайсах, то другие. ... и т.д. и т.д. и т.д.
И как правило 500 не так то и легко набрать. Обычно начинается все с 5ти прайсов, да на этом, собственно, и заканчивается. Если только не парсят тот же яндекс ))))))))))))))
А если будет 500 и более контор, то даже вообще на полную переделку денюжка будет и будет уже конкретно видно все узкие места. А часто они просто индивидуальны. Тут я не прав в том, что, конечно, хочется все заранее предусмотреть, но как правило это редко получается. И при объеме (реальном, а не мифическом и планируемом) часто много приходится переделывать чуть ли не все или наращивать железо.
Короче краткое мое мнение - нужно думать конкретно о поддержке, а не о быстродействии на текущий момент. И отталкиваться от поддержки.
При 500 надо конкретно о поддержке думать.
То одни что-нить поменяют в прайсах, то другие. ... и т.д. и т.д. и т.д.
И как правило 500 не так то и легко набрать. Обычно начинается все с 5ти прайсов, да на этом, собственно, и заканчивается. Если только не парсят тот же яндекс ))))))))))))))
А если будет 500 и более контор, то даже вообще на полную переделку денюжка будет и будет уже конкретно видно все узкие места. А часто они просто индивидуальны. Тут я не прав в том, что, конечно, хочется все заранее предусмотреть, но как правило это редко получается. И при объеме (реальном, а не мифическом и планируемом) часто много приходится переделывать чуть ли не все или наращивать железо.
Короче краткое мое мнение - нужно думать конкретно о поддержке, а не о быстродействии на текущий момент. И отталкиваться от поддержки.
scorpion-ds
Новичок
@hell0w0rd, если решение будет монолитным, то разбивка на подсервисы будет (преобразование исходного прайса к внутреннему формату, к примеру), но это можно и позже сделать.
Насчет количество клиентов, к этому стремимся, понятно что не факт что столько найдем и у большей половины будет меньше прайсов, такие цифры взяты только для тестирования.
Меня убеждают, что лучше вообще все делать на Oracle, то есть все же использовать PL\SQL, но я не представляю как это сделать в указанные сроки, тем более у нас нет Oracle разработчика.
Я не знаю деталей, но крайний скрой август, это связанно с тем, что изначально планировалось использовать написанное мной подобное приложение в прошлом году, тогда я сделал это за 1 месяц (под один магазин, но с возможностью расширения), но новое ТЗ значительно сложней, потому пришлось начинать с нуля все, тем не менее я так понимаю, что инвесторы ждут результата в августе (без SaaS, но остальная логика полностью рабочая).
Насчет количество клиентов, к этому стремимся, понятно что не факт что столько найдем и у большей половины будет меньше прайсов, такие цифры взяты только для тестирования.
Меня убеждают, что лучше вообще все делать на Oracle, то есть все же использовать PL\SQL, но я не представляю как это сделать в указанные сроки, тем более у нас нет Oracle разработчика.
Ёпт, о чём вообще тогда говорить?
Разработчика нет, грамотного ораклового DBA нет, подозреваю, что и железа соответствующего нет.
Зато есть у кого-то большое желание наступить на грабли.
Т.е. $20к на лицензию в год есть?
Я бы даже сказал - проблемы компетенций: такие решения похоже должен принимать кто-то другой. Как и нести ответственность за их последствия.
Именно так, да.
Вот забавная инерция мышления, как ораклу так и железо готовы закупать и лицензию платить и архитектора их тянуть, а как мускул, так даже мысль не закрадывается что в случае чего можно пригласить эксперта из той же перконы. аналогично с постгри.
решай проблемы по мере их поступления, делай как проще, с одной бд, но держи в уме, что возможно придётся менять. решив проблему на уровне кода ты потратишь на день больше, зато обеспечишь гибкость. вариант со 100500 дб звучит дико, а вот что сторадж захочется поменять это факт.
Работал я как-то в компании у которой был Oracle Platinum Services...
а я с ребятами из IBM, пришлось потом их гениальные запросы перепиливать и делать денормализацию, чтобы не выполнялись по 30 секунд. Вроде у них в этом году глобальное сокращение и понимаю почему, хотя это стоило делать раньше.Работал я как-то в компании у которой был Oracle Platinum Services...
scorpion-ds
Новичок
Тему Oracle закрыли, так как никто его не знает, а искать кого-то и планировать проект заново нет времени. Насчет железа, лицензии это все упомянули, но вроде, есть какая-то бесплатная версия, но я не проверял, что там такое ...
Попутно вопрос, теперь есть идея использовать "представления" в MySQL, я раньше с ними работал и на тот момент, не видел ускорения работы с ними, единственный плюс, подготовленный сложный запрос - может они реально дают какое-то ускорение?
У нас небольшая компания, по технической части решение должен принимать я, после обсуждения его с коллективом, но все эти обсуждения занимают очень много времени и мне кажутся хождением по кругу, отдельно обсуждается UI и фишки, туда я уже даже не хожу, да бы не засорять свой мозг ...
Я так и говорил (и вообще обычно так и поступаю), но от тогда задают вопрос "на сколько сложно будет потом переделывать", ответа на который я не знаю, так как пока не знаю какие могут быть проблемы и какая реальная нагрузка.
Попутно вопрос, теперь есть идея использовать "представления" в MySQL, я раньше с ними работал и на тот момент, не видел ускорения работы с ними, единственный плюс, подготовленный сложный запрос - может они реально дают какое-то ускорение?
Определись уж, ты или коллектив решения должен принимать?
MiksIr
miksir@home:~$
Думаю, у вас есть два варианта.
Вариант 1.
а) садитесь, херачите как умете не забивая себе голову цифрами, объемами и прочим "хайлоадом", запускаете рабочую версию, зарабатываете кучу бабла.
б) нанимаете тимлида/CTO в команду, с которым переписываете все с нуля уже нормально
Вариант 2.
То же, что и вариант 1, только без пункта а)
Вариант 1.
а) садитесь, херачите как умете не забивая себе голову цифрами, объемами и прочим "хайлоадом", запускаете рабочую версию, зарабатываете кучу бабла.
б) нанимаете тимлида/CTO в команду, с которым переписываете все с нуля уже нормально
Вариант 2.
То же, что и вариант 1, только без пункта а)
с кучей ограничений на ресурсы
нельзя такmaterialized views дают, а обычные мускульные нет, от них польза только в упрощении запроса из приложения, да и то, если наколбасишь EAV, то вьюхи тебе не помогут
scorpion-ds
Новичок
Мне тоже такой подход нравится, а дальше будет видно.
Ну да, я так и думал, но тот кто советовал Oracle убеждал, что они значительно ускоряют запросы.
Вчера вроде приняли решение делать от простого к сложному, и без всяких нагрузочных тестов (на текущий момент), далее оценить проблемы и исправлять их с переписыванием при необходимости кода (без костылей), но обсуждение было без PM-а, можно предположить, что он не согласится.