Вхід і реєстрація
Розробка · 9 березня 2021, 12:46 3824
Vitaliy Bondarchuk

Какой стек backend+database вы бы рекомендовали?

Добрый день,

Планирую вот такое: кабинет для отеля, куда отель будет вносить свою инфу: фотки, описание, и тп. Но главное, что отельер создает и вносит тарифы в этот кабинет. У одного отеля может быть около 30 тарифов с ценами на каждый день года. Итого грубо 11к записей. В базе 2000 отелей. Получаем 22млн записей. История этих записей должна храниться т.к. и цены отельер регулярно меняет, и сегодня бронировка сделана по одной цене, а завтра по другой. Плюс к ценам могут применяться скидки. К этому «счастью» будут идти запросы на разные диапазоны дат. Нужно быстро найти, посчитать и отдать цену.

Вопрос к знатокам: какой стек backend+database вы бы рекомендовали?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Sergey Lysak 09.03.2021 15:37

типичная и обычная задача для РСУБД
Проектировать — от данных, а потом брать бекенд что лучше всего знаете (вы+команда)
Основная нагрузка все равно будет на БД
Если сделаете наоборот, от ORMа, DDD и т.д. — почти гарантировано нарветесь на много боли, когда вся эта объектно ориентированная красотень начнет безбожно измываться над БД и вам все равно придется, уже мучительно — оптимизировать.

NoSQL вам не помогут, особенно если не делали на них реальных проектов.
А по тому как добиваться от РСУБД пристойных результатов — тьма материалов, так что если и не очень знаете сейчас — сможете добрать информации, про кластера, репликации, шардирование с партицированием, и т.п..

По озвученным вами цифрах потянет и MySQL/MariaDB

Если работали с PostgreSQL, или уверены что надо освоить и даст выгоды — берите ее.

Перейти до дискусії
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Vitaliy Marenkov Back-end developer – eTravel S.A. 13.04.2021 18:27

Все тут обсуждают большие объемы данных, количество запросов. Но я вот тут понял одну вещь — а ведь данные разных гостиниц вообще между собой не связаны. Если используемый сервер исчерпает свои возможности, ставьте новый пустой инстанс на новый сервер и начинайте наполнять его новыми клиентами — им не нужны данные других гостиниц. Исключение — сети гостиниц, но во первых у них обычно свое по, а во вторых, дня них можно вообще отдельный сервер. Так что пишите на чем вам удобнее.

Відповісти
Підтримати
Sergey Solution Architect 17.03.2021 07:00

если взагали по загалям, то до 100 млн записей в относительно небольшом конкурентном режиме (условно десятки относительно нетяжелых запросов) в секунду потянет любой нормальный sql движок. На самом деле потянет и гораздо больше, но там уже над уметь его конфигурить, а автор, судя по вопросу — не умеет. Бекенд — любой, совершенно непринципиально.
Но ближе к имплементации скорей всего начнут вылазить интересные тонкие моменты, и к этому надо быть готовым :)

Відповісти
Підтримати
Alexandr Gavriluk 13.03.2021 21:27
У одного отеля может быть около 30 тарифов с ценами на каждый день года. Итого грубо 11к записей. В базе 2000 отелей.

PostgreSQL с партиционированием таблиц по ID отеля.

Відповісти
Підтримати
Igor Lytvynenko Co-Founder в Artellence 13.03.2021 15:18

Я б розглянув варіант не вбиватися в академічну реляційну БД.

Один тариф на місяць для всіх номерів влізе в один json.

При бронюванні, тариф з усіма даними копіюється в замовлення так щоб не тримати зв’язок на «зовнішнє» джерело даних.

Єдине, що для такого підходу треба обирати backend, де можна в пам’яті тримати гарно розкладений той json в зручну in-memory структуру, яку постійно всю тримати в пам’яті (щось схоже на кеш).

А самі json-и, можна навіть в gzip тримати в blob в БД, там і версіювати.

Мінус такого підходу в тому, що треба забути про запити всередину того json. Але плюсом є те, що структуру можна зробити «природною» для даних, in-memory буде працювати дуже швидко, а БД буде дбати лише про «persistance».

Відповісти
Підтримати
Sergiy Morenets Java evangelist 12.03.2021 21:01

Віталій, ви не написали найголовніше — де це все буде крутитися.
На виділеному сервері, cloud або десь ще. Від цього дуже сильно залежить які технології використовувати, так як варіантів дуже багато.

Відповісти
Підтримати
Vic Programmer 10.03.2021 15:40

У вас получается кастомизированный eCommerce. Довольно сложный enterprice. Мы делали подобное на следующем стеке: Java, Spring Framework, Apache Solr (поиск для пользователя), Drools (рантайм кофигурирование скидок), Oracle (или PostgreeSQL). Возможно еще понадобится интеграция с ERP — напирмер 1С или SAP. + Место где разворачивать например AWS или Azure. Соответственно СI/CD и три энва. Prod/UAT/CD. Можно попробовать приспособить eCommerce framework. Скажем www.broadleafcommerce.com Так или иначе сначала нужно четко понять объем работ, выявить требования и т.п.

Відповісти
Підтримати
Sergiy Morenets Java evangelist 12.03.2021 20:55

Oracle занадто круто для такої системи. Postgres з головою вистачить (а може навіть і MySQL)

Відповісти
Підтримати
Vic
Vladyslav Ml Software Engineer в GlobalLogic 12.03.2021 21:18

Есть Oracle Apex там вообще все мышкой в конструкторе можно сделать. Работает на бесплатном Oracle XE. Для этой задачи хватит. По скорости разработки думаю конкурентов нет.

Відповісти
Підтримати
Sergiy Morenets
Nikita Podgorbunskyi Software Engineer 10.03.2021 12:18

Вообще так почитав тему и задачу я бы вам порекомендовал четко выписать требования к системе, а так же продумать примеры использования. Простой пример

Но главное, что отельер создает и вносит тарифы в этот кабинет. У одного отеля может быть около 30 тарифов с ценами на каждый день года. Итого грубо 11к записей.

Нет, вам лишь надо 365 + 30 записей на один отель в год.

Відповісти
Підтримати
Vitaliy Bondarchuk 10.03.2021 12:35

Не так. У условного отеля есть 3 категории номеров, в каждой может жить 1-2 человека. Уже получим 6 цен. Плюс тариф может быть стандартный или невозвратный, и это под каждую категорию и проживание. Получаем 12 цен на 1 день. 365 дней *12 = 4380. Если в базу занесем например 2000 отелей, тогда почти 9млн. Если отели будут применять скидки, еще больше. И это я еще посчитал очень «по бедному». Короче записей действительно очень много.

Відповісти
Підтримати
Nikita Podgorbunskyi
Dmytro Zemnytskyi Засновник в Pragmasoft, Харків 10.03.2021 13:14

Я тут відповім одразу всім.

1) Проблема зі зберіганням за кожен день навіть не в тому, що це багато даних, а в тому, що їх комусь треба ще вводити або ще гірше — міняти, тобто це досить гнучко, але буде незручно користувачам. Це одна з причин, чому наприклад для контроля доступу використовуються групи, а не окремі записи користувачів.

2) А що як зберігати окремо базові ціни та коефіціенти? Ну скажімо, категорія номеру зберігає ціну, а окремо зберігаються коефіціенти (невозвратний x 0.8, високий сезон х 2.0... ) Тоді нам потрібно не M*N рядків, а тільки M+N? Для цього правда потрібно, щоб для усіх категорій коефіціенти застосовувались однаково, це досить ймовірне припущення, як на мене.

3) Якщо коефіціенти зберігати як я пропонував з діапазоном дат а не з конкретною датою, то PostgreSQL має суттєву перевагу над MySQL/Maria — він має диапазонний тип даних (Range), у тому числі й для диапазонів дат, а також GIST індекси, які роблять запроси по діапазонах досить ефективними. я правда не знаю як справи з підтримкою цих типів у PHP/Symphony, бо я не PHP програмист, але сподіваюсь, що вона є.

Відповісти
Підтримати
Vitaliy Bondarchuk
Sergey Lysak T/T Lead 10.03.2021 15:46
Короче записей действительно очень много.

это не много. главное не количество записей, а размер в байтах который нужно прочитать и передать приложению. а id отеля, комната(категория), дата, цены — это в байтах будет немного.

и, так как наверняка цены будут совпадать, а у вас PostgreSQL, то
ALTER TABLE room_prices
ALTER COLUMN price
SET ORIENTATION COLUMN;
погонять конечно на типичных запросах, будет ли выгода
id отелей по идее тоже в такую же колонку превратить

дату хранить числом в часах, от 1 января 20??
в часах, а не днях — может оказаться что отелю важно время смены цены.

и ручное или авто партицирование — старые цены хранить в другой таблице
и отели сгруппировать, скажем по географическому принципу, и для каждой группы — своя таблица цен той же структуры
скидки — отдельно, джойнить
и т.д. и т.п.

вот например уже посерьезней:
Приблизительные объемы:
~ 80 млн SKU (артикулов) мы знаем
~ 60 млн можем привезти
~ 150 000 SKU лежит на складах
~ 240 млн записей по аналогам
> 10 000 входящих прайс-листов (максимальный размер прайс-листа 8.5 млн строк), частое обновление цен и наличия
MySQL под нагрузкой > 40000 QPS, что может пойти не так
telegra.ph/...​mozhet-pojti-ne-tak-02-04

Відповісти
Підтримати
Vitaliy Bondarchuk
Oleg Kostyuk Героям Слава в Україні 17.03.2021 02:14

Согласно www.postgresql.org/...​rrent/sql-altertable.html,

SET ORIENTATION COLUMN

в ПГ не поддерживается .
Хотя есть некий wiki.postgresql.org/...​iki/ColumnOrientedSTorage, но тут нет указания на версии ПГ, где оно работает.
Проясните плз, что это и откуда, с какой версии и как включать?

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 17.03.2021 08:29
Проясните плз, что это и откуда, с какой версии и как включать?

не вникал, нагуглил. именно эту wiki.postgresql.org

в ПГ не поддерживается .

значит не поддерживается.

Postgresql не использовал в деле. пробовал, но его возможности показались избыточными, а «платить» за эту избыточность — надо. при этом в сценариях много читаем мало пишем — выгод особых нет, а нередко и хуже.
на днях даже статью с замерами встретил об этом. линка не сохранил.

Он крут конечно, если ..., если ..., и если ...

в данном случае отсутствие колумн ориентированности ничего особо не меняет.
так, интересно — будет ли ощутимый эффект.

Відповісти
Підтримати
Oleg Kostyuk
Nikita Podgorbunskyi Software Engineer 10.03.2021 15:57

Так будет побольше, но не радикально больше. Можно обойтись группой и в каждой записи хранить базовую цену и факторы которые отвечают за ценнобразование пересчитывая все это по таймеру и/или по событиям(новая бронь или какое-то событие в городе). В реальности все это работает вполне сносно.
Скажем есть у вас есть номер Сингл, Дабл и Люкс. В каждом из которых у вас по 10 комнат. Тогда самый простой вариант это иметь базовую цену на каждую группу в каждый конкретный день и в этой же записи хранить число обозначающее количество свободных номеров в этой категории в этот день (так делает экспедиа и ко).

Если отели будут применять скидки, еще больше.

Скидки скидки могут быть разного типа если это скажем С ПО то это просто повлияет на записи базовых цен и калькуляцию по итогу без увеличения количества записей, а если это покупка на 1000+ баксов то ее надо считать во время бронирования.

Відповісти
Підтримати
Vitaliy Bondarchuk
Sergey Lysak T/T Lead 10.03.2021 16:09
В реальности все это работает вполне сносно.

в реальности цена — это фантазия маркетолога. не имеющая никакой базовой, коэфов, и прочих формул

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

первичные данные надо стараться хранить так как они звучат.

и факторы которые отвечают за ценнобразование

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

а достаточно пары процентов исключений из «формульной красоты» — чтобы пришлось потом муторно костылить систему.

Відповісти
Підтримати
Nikita Podgorbunskyi
Andrey Rogovsky Допомагаю знайти першу роботу IT для Трейні та Джунів в TOPIZDATO: Соціальна IT-екосистема 10.03.2021 07:18

Ну а теперь правильный ответ:
1. Делаем на WordPress, где есть туева хуча плагинов под это все.
2. Таблицу с ценами, скидками и прочей требухой отельеры экспортируют в google sheet по датам
3. Настраиваем синк в вукомерс через плагин по крону
4. ???
5. Profit

Итого — все решение это одна крон джоба.

Відповісти
Підтримати
Sergiy Morenets Java evangelist 12.03.2021 20:56

За таке рішення жоден замовник не заплатить мільйон доларів.

Відповісти
Підтримати
Andrey Rogovsky
Andrey Rogovsky Допомагаю знайти першу роботу IT для Трейні та Джунів в TOPIZDATO: Соціальна IT-екосистема 13.03.2021 06:50

Заказчику плевать на то, что под капотом. Если ему это приносит миллиарды — заплатит миллион.

Відповісти
Підтримати
Sergiy Morenets
Олексій Пєніє 10.03.2021 05:35

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

Рекомендую стек продаж. Потому что вероятнее всего у тебя нет ни малейших шансов продать хотя бы 1 такой кабинет, просто потому что нет ни ресурсов, ни опыта чтобы преодолеть порог вхождения.

Ну и компетенция в IT сомнительна, поскольку хранить по 1 записи цен на каждый день — сомнительно. Храни текущую актуальную. Храни цены на будущее. А старые не храни, они тебе нахрен не нужны, если только ты не собрался автоматизировать внутреннюю бухгалтерию.

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

PS. А что ты будешь делать, если цена поменяется в течение дня? Ну, например если внесли по ошибке неправильную, как ты будешь хранить историю, если эта строчка в таблице уже есть, и вторую такую же вставить не даст? Мне кажется, ты вообще не сильно смыслишь в деталях этого бизнеса. А без проработки деталей твой проект даже не MVP, а просто кусок дерьма с точки зрения владельца бизнеса. И поверь, тебе надо быть перфекционистом, чтобы в это сунуться.

Відповісти
Підтримати
Vitaliy Marenkov Back-end developer – eTravel S.A. 10.03.2021 12:52

Цены на номера в гостиницах — это не цены товаров, цена одного и того же номера может меняться в зависимости от дня недели, выходных, праздников, расписания авиарейсов, и т.д. И тут есть два решения — либо цены для диапазонов дат (сложно), либо цена на каждый день (много данных). Старые цены действительно можно удалять сразу же, цены зарезервированных номеров останутся в резервациях, а остальные больше не нужны. Но все равно надо хранить их на год вперед.

Відповісти
Підтримати
Олексій Пєніє
Dmytro Zemnytskyi Засновник в Pragmasoft, Харків 10.03.2021 01:31

Щось мені здається, що розмір дуже переоцінений. Реально готелі ціни міняють не кожен день, а декілька разів на рік — високий, низький сезон, та міжсезоння. Та й 30 тарифів — то для досить великих готелів, таких небагато, більшість невеликих, тобто 30 то максимум а не медіана, медіану я б брав десь 5, а краще б порахував, бо схоже що дані вже є.

З цього розрахунку, оперативних даних зовсім небагато, навіть враховуючи необхідність збереження історичних даних.

Взагалі думаю що нічого нетривіального тут нема, Symphony + PostgreSQL досить адекватний стек.

Відповісти
Підтримати
Vitaliy Marenkov Back-end developer – eTravel S.A. 10.03.2021 12:55

Залежить від готелю. В деяких ціни змінюються як ціни квитків на літак.

Відповісти
Підтримати
Dmytro Zemnytskyi
Олексій Пєніє 10.03.2021 05:39

Слова истинного эксперта в любом вебе.
Синдром Даннинга-Крюгера комфортнее проходить помедленнее, насладись моментом. Правда цена за это... а впрочем, зачем думать о таких мелочах. Когда тебе любой веб по плечу и море по колено

Відповісти
Підтримати
anonymous
Vladyslav Melnyk 10.03.2021 11:16
много спецов

Смело делить на 3, потому что вошли из-за низкого порога.

быстрый запуск и разработка прототипов

Смотря какой прототип и какие требования к нему.

скорость разработки одна из самых высоких

Почему?

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

Сколько Вы подняли проектов на отличном от пхп языке?

Відповісти
Підтримати
anonymous
Sergey Lysak T/T Lead 10.03.2021 12:09
Почему?

помимо того что есть у других
Однопоточность кода, семантическая выразительность, опциональный контроль типов, отсутствие состояния у приложения, потому что приложения — нет.

Сколько Вы подняли проектов на отличном от пхп языке?

не считал. да и не имеет значения, описание крупных проектов на php легко гуглится.

как имеющий опыт и на Джаве добавлю, что в домене финансового-экономического ПО — php уже нередко более лучший выбор, чем Джава/.NET
то что у него дурная репутация времен древних версий — дело такое. Собаки лают, а караван идет.

то же чего нет у php — делается в виде отдельных сервисов на ЯП в которых это есть. А это обычно — не более «20%» функционала системы.

Відповісти
Підтримати
Vladyslav Melnyk
Vladyslav Melnyk 10.03.2021 18:27
Однопоточность кода

В нем же вроде есть треды, если нет то почему это плюс? Что по async/await либо reactive подходам из коробки?

опциональный контроль типов

Ничего не мешает говнокодить на .net и dynamic принимать. Насколько это хорошо — хз.

не считал. да и не имеет значения, описание крупных проектов на php легко гуглится.

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

как имеющий опыт и на Джаве добавлю, что в домене финансового-экономического ПО — php уже нередко более лучший выбор, чем Джава/.NET

Так а чем лучше то?=)

то же чего нет у php — делается в виде отдельных сервисов на ЯП в которых это есть.

+ время на интеграцию
+ поиск спецов с другим стеком
+ трата денег чтобы держать человека в штате на случай чего.
Да блин, даже если надо добавить какой-то serverless функционал — в aws/lambda functions нет рантайма для php :D
Готов поспорить что любой api пишется что на .net что на php что на ноде одинаково быстро.

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 10.03.2021 19:21
В нем же вроде есть треды, если нет то почему это плюс?

очевидно ж что
однопоточный код писать легче многопоточного или асинхронного.

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

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

я писал профессионально и на С, и на Джаве, и вот на PHP
Мне — очевидно чем обеспечивается скорость разработки на PHP.
Проверено многократно, в том домене в котором обитаю.

Выше написал основные фичи PHP которые дают это преимущество.
На Питоне — будет сопоставимо.

Так а чем лучше то?=)

тем что скорость разработки ощутимо выше.

время на интеграцию

такое же как и в других яп.

вы же очереди на коленке уже не пишите?
и такого добра уже полно.
Скорость по добавлению в проект — такая же.

поиск спецов с другим стеком

Go прекрасно осваивается пхпистами.
Тем более что когда он нужен — то нужно что-то примитивное, простое. И не требует глубоких знаний Go

трата денег чтобы держать человека в штате на случай чего.

а если проект с SPA — то на нем нодщики все равно есть.

Написать простой сервис для бека — смогут.

даже если надо добавить какой-то serverless функционал — в aws/lambda functions нет рантайма для php

и вряд ли будет.

потому что тьма проектов не нуждаются в serverless.

Готов поспорить что любой api пишется что на .net что на php что на ноде одинаково быстро.

на ноде — медленнее. потому что там — асинхронщина.

а пхп код — однопоточный.

другое дело что тьма проектов имеют примитивный бекенд, и поэтому этой разницей можно пренебречь.

Відповісти
Підтримати
Vladyslav Melnyk
Oleksandr Bereziuk Solution Architect в Vitality Group Inc 16.03.2021 17:47
а пхп код — однопоточный.

А просветите человека ни разу не видевшего пхп, что значит «однопоточный» ? Один поток исполнения на-все-про-все? Ну типа один http-запрос подвис, и все — отказы в обслуживании? Или производная от CGI-BIN ?

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 16.03.2021 17:54
А просветите человека ни разу не видевшего пхп, что значит «однопоточный»

то что отсутствует потребность думать о потоках или асинхронщине, потому что просто нет возможностей.
они конечно есть, но даже в сравнении с питоновскими — никакие.

Ну типа один http-запрос подвис, и все — отказы в обслуживании?

запрос принимает — веб сервер.
далее он, веб сервер, или кто вместо него, запускает на выполнение — отдельное приложение php.
одновременно их может быть запущено сколько памяти хватит.
суть — это однопточные приложения, и с синхронным I/O

есть конечно всякие возможности мимо этой схемы. и возможность в асинхронном режиме запустить, и RoadRunner (youtu.be/RUm94xCaXMo)
но суть все же

на каждый входящий http-запрос — отдельное однопоточное приложение.
что очень все упрощает при разработке :)

Відповісти
Підтримати
Oleksandr Bereziuk
Oleksandr Bereziuk Solution Architect в Vitality Group Inc 16.03.2021 18:10

То есть, если php-скрипт работает с БД, то при каждом запуске, на каждый входящий запрос, создается новый коннект ?

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 16.03.2021 18:15
То есть, если php-скрипт работает с БД, то при каждом запуске, на каждый входящий запрос, создается новый коннект ?

да.
поэтому у БД должен быть шустрый пул коннектов, как у MariaDB
либо ставить такой перед ней, забыл как там штатный для Postgres называется.

в сравнении с типичным временем выполнения
затраты на создание нового коннекта мизерные.
даже бустрап нового приложения, от 30 до 70 мс у толстых php фреймворков — не критичен, когда только чисто БД будет отрабатывать пару сотен мс. а она будет отрабатывать столько же хоть с нодовского, хоть с джавовского приложения шли запрос :)

синтетические тесты:
www.techempower.com/...​data-r20&hw=ph&test=query

Відповісти
Підтримати
Oleksandr Bereziuk
Oleksandr Bereziuk Solution Architect в Vitality Group Inc 16.03.2021 18:34
даже бустрап, от 30 до 70 мс — не критичен

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

на каждый входящий http-запрос — отдельное однопоточное приложение.

То есть новые фичи http/2 пролетают?

В любом случае спасибо за информацию.

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 16.03.2021 18:37
Сомневаюс что бутстрап не критичен

посмотрите на статистику сайтов — топ 1 000 000 — на чем сделаны.

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

то что завезли в 8.0 и собираются в 8.1 — указывает что доля эта и дальше будет расти. люди ж просят, за php нет никого — кроме запросов комьюнити на развитие.

То есть новые фичи http/2 пролетают?

эти фичи обеспечивает веб сервер
они прекрасно работают.

В любом случае спасибо за информацию.

пожалуйста.
и выздоравливайте от хейтинга.
он не конструктивен — а всего лишь способ остаться при своем неосведомленном мнении:)

Відповісти
Підтримати
Oleksandr Bereziuk
Oleksandr Bereziuk Solution Architect в Vitality Group Inc 16.03.2021 18:50
посмотрите на статистику сайтов — топ 1 000 000 — на чем сделаны.

Ну так для сайтов, в классическом понимании, php и был предназначен изначально. Но то и Personal Home Page

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

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

и выздоравливайте от хейтинга.

У меня его нет. Я уже давно перерос языковые холивары.

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 16.03.2021 18:53
и был предназначен изначально.

да.
а Java изначально для эмбедед ПО кофеварок.
А js — для мелких скриптиков посреди html

Вот в этом не уверен, просто по количеству вакансий.

Java 572
.NET 531
PHP 529
это с jobs DOU. Учитывайте что у нас в Украине — эти вакансии формирует — преимущественно аутсорс — т.е. легаси фиксать.

php ессно не вытеснит из энтерпрайза ни джаву ни дотнет.
по тьме объективных причин умноженных на субъективных.

а просто, до какого-то уровня — будет увеличивать свое присутствие в типичном энтерпрайзе, где лет 15 тому им и не пахло

У меня его нет

не телепат.
просто и вопросы и аргументы у вас типичного хейтера :)

Я уже давно перерос языковые холивары.

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

Відповісти
Підтримати
Oleksandr Bereziuk
Oleksandr Bereziuk Solution Architect в Vitality Group Inc 16.03.2021 19:06
а Java иначально для эмбедед ПО кофеварок.

И для апплетов. Ужасная технология была.

Java 572
.NET 531
PHP 529

Это всего. Посмотрите на вакансии крупных компаний (== самый энтерпрайзный энтерпрайз). Там очень мало php.

просто и вопросы и аргументы у вас типичного хейтера :)

Врага надо знать в лицо (шутка :). Я просто примерно представляю потенциальные узкие места, вот и хотел уточнить правильность понимания.

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 16.03.2021 19:22
И для апплетов. Ужасная технология была.

а Java — осталась :)

Это всего

в мире. да.

Посмотрите на вакансии крупных компаний (== энтерпрайз).

недавно на доу была статья от тех лида — крупной компании.
американской. как они легаси на php рефакторили. внутреннее.

Там очень мало php.

где — «там»?
вакансии тех лидов на php уже и в епамах появились.

конечно было бы странно что после такого количества работающего софта на «джаве», вдруг все стали его переписывать, или переучивать команды на другое.

Врага надо знать в лицо

для этого надо излечиться от хейтинга :)
ну типа — враг — значит дурак, неуч, и т.п.
ну типа как немцы в советском кино 40ых-60ых.

Я просто примерно представляю потенциальные узкие места

я тоже их знаю.
и знаю узкие места джавы. Потому что писал на ней профессионально, и GUI и энтерпрайз. Многопоточный, все дела.

вот и хотел уточнить правильность понимания.

думаю не получили, если не поняли почему php для кофеварок, тьху, джава для сайтиков, тьху

вобщем почему пхп все чаще встречается в суровом, типичном энтерпрайзе.
и никакого html не генерит, а в качестве обычного бекенд приложения с API для SPA

Відповісти
Підтримати
Oleksandr Bereziuk
Oleksandr Bereziuk Solution Architect в Vitality Group Inc 16.03.2021 19:55
как они легаси на php рефакторили. внутреннее.

То что практически любое легаси старше десяти лет имеет смысл ( конечно при наличии возможности ) переписывать на практически любой язык актуальной версии, сомнения не вызывает. Выбрали php, в силу каких-то причин, ну Ок, им наверняка виднее по месту. Только вот обобщений из этого не следует аж никак

для этого надо излечиться от хейтинга :)

Специально добавил «шутка»

и знаю узкие места джавы.

Просто ради интереса, какие сейчас узкие места, по вашему мнению (начиная с версии 8+) ?

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 16.03.2021 20:09
Выбрали php, в силу каких-то причин, ну Ок, им наверняка виднее по месту.

на php и переписали :)

Только вот обобщений из этого не следует аж никак

я предложил пару зацепок для того чтобы вы увидели — тренд.
но хейтерство — делает слепым. о том сразу и написал :)

хейтерство — это объективная вещь. поселяется в мозгу мимо выбора хозяина. если он не следил специально, чтобы не поселилось :)

Специально добавил «шутка»

да я ж тоже так, мимолетом сурьезный :)

Просто ради интереса, какие сейчас узкие места

те же.

Достоинства и есть недостатки.
А недостатки — это оплата достоинств. или тоже — они же и есть.

Ласты — классная штука. И лыжи — тоже.
Так что берем в Альпы ласты, а в Египет — лыжи, и радуемся.

«А на вашей джаве — драйвер видеокарты нельзя написать!» — говорили плюсовики когда я был в джаве. «гадость эта ваша джава!»
«А на вашей джаве — gui уродливое!» — говорили дельфисты. «гадость эта ваша джава!»

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

Достоинства же и недостатки вы сможете сами увидеть, просто почитав соответствующие статьи.

доку пересказывать — неинтересно.

а вот заблуждения людские, в частности забобоны, догматы веры программерские — да, вот это интересно!
мне конечно :)

Відповісти
Підтримати
Oleksandr Bereziuk
Volodymyr Yefremov Laravel/Vue.js dev в - - - 10.03.2021 12:10
3. симфа структурирует не совсем прямые руки разрабов на пхп
4. быстрый запуск и разработка прототипов
5. скорость разработки одна из самых высоких

я за Ларавел — прибавляет еще и удовольствие :)

Відповісти
Підтримати
anonymous
Volodymyr Yefremov Laravel/Vue.js dev в - - - 10.03.2021 12:08

а что не так в комменте Виктора?
слово «любой»?

Відповісти
Підтримати
Олексій Пєніє
minodvesP Vasya 10.03.2021 14:45
на symfony (php) + реляционная бд по типу Postgresql/mariadb

..или руби с рельсами, или питон с джангой. :-) (в зависимости от того, какой язык топикстартер лучше знает, если знает пхп. то тогда на пхп)

Відповісти
Підтримати
anonymous
anonymus ps 09.03.2021 20:05

Да любой который вы знаете

Відповісти
Підтримати
Nikita Podgorbunskyi Software Engineer 09.03.2021 18:26

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

Відповісти
Підтримати
Sеrgejs Bоrуsson Senior Tractorist 09.03.2021 16:19

Наскільки я розумію задачу — швидко треба віддавати тільки поточні ціни для того щоб швидко порахувати ціну на вибрані дати.
тож ми маємо 60к тарифів і кожен таріф — массив float на 365 елементів.
Тобто питання навантаження і кількості рядків в базі вирішується через кеш на 60к рекордів, кожна по 365*4 = 1460 байт. Тобто загалом 87,6 кілобайт пам’яті в кеш. Звичайно прогноз Біллі Гейста про достатні всім 64к не виконуються, але проблемою це було мабуть тількі років 40 тому назад.
Соррі, калькулятор загубив. 85 мегабайт. Одна хрєнь.

Відповісти
Підтримати
Олексій Пєніє 10.03.2021 05:41

Не вгадав. Старі тарифи нікому не цікаві, якщо є паранойя їх зберігати — то в окремій таблиці. Куди більшість запитів взагалі не звертається.

Відповісти
Підтримати
Sеrgejs Bоrуsson
Sеrgejs Bоrуsson Senior Tractorist 10.03.2021 06:28

Ні, тарифи не старі — це типу різні типи номерів (single, double, superior, etc). Не цікаві історія цін по цих тарифах. Зберігати можна як завгодно — головне тримати кеш актуальних тарифів які займають 85МB і це ще без оптимізації.

Відповісти
Підтримати
Олексій Пєніє
Max Melnyk Software Engineer в People.ai 09.03.2021 15:56

Скала + постгрес + какая-то вертика или кликхаус для олап.
Все на aws в контейнерах и кубернетисах и поставлять в тераформе.
Не забыть прикрутить прометеусы и графаны.
Хорошо бы настроить кетчпоинты.

Відповісти
Підтримати
Max Melnyk Software Engineer в People.ai 09.03.2021 15:58

и Кафка топики, точно

Відповісти
Підтримати
Max Melnyk
Sergey Lysak T/T Lead 09.03.2021 16:02

без кафки да, позапрошлый век, загон мамонта каменьями и кольями.

Відповісти
Підтримати
Max Melnyk
Vlad Stelmahovsky Software Engineer в Verity AG 09.03.2021 16:48
без кафки

гьефневой?

Відповісти
Підтримати
Sergey Lysak
Вуйко з Канади 09.03.2021 17:21

1. Ну зі Скалою ви звичайно послали топікстартера )) А потім найди хоть когось за адекватні для аутсорса гроші.
2. Якщо ви вже пропонуєте конкретно AWS, то чому Кафка, а не SQS(чи SQS FIFO)? Менеджед сервіс, сам скейлиться, сам обслуговується, голова не болить.

Відповісти
Підтримати
Max Melnyk
Max Melnyk Software Engineer в People.ai 09.03.2021 17:24
Менеджед сервіс, сам скейлиться

Согласен, можно идти на уровень выше, нанять контору которая тебе все запилит) Такой себе менеджт IT :)

Відповісти
Підтримати
Вуйко з Канади
Вуйко з Канади 09.03.2021 17:31

Підозрюю, що топікстартер і є та кантора :)
Ну, короче аргументів щоб тягнути сюди Кафку, тут не бачу. Якщо можна прив’язатися до AWS.

Відповісти
Підтримати
Max Melnyk
Sergey Lysak T/T Lead 09.03.2021 17:32
аргументів для Кафки тут не бачу.

резюме драйв девелопмент — це Аргумент!

Відповісти
Підтримати
Вуйко з Канади
Max Melnyk Software Engineer в People.ai 09.03.2021 17:33

Единственный аргумент это деньги) другого быть не может. Не зря же есть уже роли типа AWS Developer.

Відповісти
Підтримати
Вуйко з Канади
Вуйко з Канади 09.03.2021 17:47

Ну, гроші — то давня тема холівару, Не все так однозначно©, але зайвий раз пропоную не розводити холівар)

Відповісти
Підтримати
Max Melnyk
Vitaliy Bondarchuk 09.03.2021 18:18

Копипастер не кантора, и холивар не стартит )) Кто такой копипастер я с горем пополам понял, но что за «холивар» — пришлось реально гуглить :)) Описанный в топике продукт, у меня «почти» есть. Я не кантора, и даже не разработчик. Я в какой-то степени продакт менеджер. Делаю для себя, т.к. работаю в этом бизнесе, и деньги позволяют спонсировать эту вечеринку. Продукт есть еще с 2019г. Так получилось, что не доделали до конца. Написан на Symfony+PostgreSQL. Насколько «почти»? Не знаю. По работающему функционалу % на 70. Но, например тесты нагрузки не проводились. Вот и стоит дилемма: или найти аутсорсера, который будет разбираться в чужом коде и доделает, или взять новый стек и сделать с нуля. Конечно на бюджет тоже смотрю. Вариант Golang — дорого.
В любом случае ВСЕМ спасибо за мнения.

Відповісти
Підтримати
Вуйко з Канади
Вуйко з Канади 09.03.2021 18:32

Ага, це важливі уточнення.
Насправді там топікстартер (topic starter) — той, хто створив тему. :)
Стек популярний, на ньому цілком можна написати таке.
Найважливіше питання — чому не дописали.
— Якщо закінчилися фінанси і вам прийшлося зупинити розробку — то одне.
— Якщо девелопери шось наваяли і свалили, або не змогли справитися з задачами — то зовсім інше. Тут найбільший ризик в якому воно стані. В переводі на людську мову то звучить десь так: продаю авто по фотографії. Їде на першій передачі, треба докрутити ще кілька передач. Ось фото машини.
Тому... з порад... якщо деви були хороші — то найти їх і попросити доробити. Точно буде найдешевше. Якщо таке не підходить — то тут простих порад нема. Тре дивитися шо в вас там в коді, шо там в ріквайроментах і оцінювати.

Відповісти
Підтримати
Vitaliy Bondarchuk
Vitaliy Bondarchuk 10.03.2021 09:23

Цілком згоден про «авто по фото». Але в мене трішки по іншому. Враховуючи, що я не розуміюся на авто, я тому і цікавлюся, з яких матеріалів його краще зібрати. Виходячи із наявного, мій стек — норм. Тоді наступний крок — аналіз коду. Буду шукати фріланс. Дякую.

Відповісти
Підтримати
Вуйко з Канади
Sergey Lysak T/T Lead 09.03.2021 18:34
Написан на Symfony+PostgreSQL.

тогда стоит поискать команду — и дописать.

взять новый стек и сделать с нуля.

новый стек ничего особенного не даст вместо указанной связки.

В ней главный элемент — PostgreSQL.
Symfony, если зрело используется, это считайте Java/.NET. то есть замена Symfony на Java/.NET — ничего существенного не даст.

который будет разбираться в чужом коде

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

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

ну тогда пусть выкатывает план работ на написание с нуля.

Конечно на бюджет тоже смотрю

на Symfony будет дешевле/быстрее всего, чем на любом другом.

но, еще раз, главное — PostgreSQL. Остальное — не важно.
Если новая команда не шарит в PostgreSQL — то эта команда не ваш выбор.

Відповісти
Підтримати
Vitaliy Bondarchuk
Vitaliy Bondarchuk 10.03.2021 09:25

Спасибо. Сделал вывод, что мой стек — норм. Перехожу на след шаг. Буду искать фриланс для оценки того, что есть и завершения работы.

Відповісти
Підтримати
Sergey Lysak
Volodymyr Yefremov Laravel/Vue.js dev в - - - 10.03.2021 12:46
на Symfony будет дешевле/быстрее всего, чем на любом другом

что скажете про Ларавел?

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 10.03.2021 13:04
что скажете про Ларавел?

более быстр в разработке. на старте :)
дальше — зависит от того понимала ли команда что делает :)

Symfony — это ж как бы и не фреймворк, а конструктор, набор модулей, компонент, и «рекомендаций» по их интеграции.

И, в Symfony много тяжеловестно энтерпрайзных решений, с оглядкой на Джаву. Еще более «джавовским» был Zend

Поэтому и выбор — если несколько команд, если приложение будет точно сурово энтерпрайзное — как по функционалу, с головомуторной бизнес логикой, и т.д., так и по самому процессу разработки то — Symfony

Я же для текущего проекта выбрал Yii2. Не поддаваясь на соблазн ActiveRecord использовать в качестве domain model :)
У проектов на Ларке нередко та же беда, народ радостно начинает ActiveRecord использовать в качестве domain model, потому что это быстро кодить, и фреймворк как бы толкает к этому.
А если продукт развивается-усложняется — начинается боль.

persistence model только для условного бложика тождественна domain model, и не требуется ничего архитектурить — как фреймворк предлагает так и делай.

Symfony же сразу напрягает — надо вначале продумать выбрать архитектуру приложения.
и Doctrine сделана опять же, как Hibernate.
И проблемы те же в итоге :)

За все надо платить.

Відповісти
Підтримати
Volodymyr Yefremov
Volodymyr Yefremov Laravel/Vue.js dev в - - - 10.03.2021 15:32

Спасибо за подробный и понятный обзор!

Відповісти
Підтримати
Sergey Lysak
Volodymyr Yefremov Laravel/Vue.js dev в - - - 10.03.2021 12:44
Написан на Symfony+PostgreSQL.

ну вот — оптимально :)

Відповісти
Підтримати
Vitaliy Bondarchuk
Oleksandr Serozhenko Technical Lead Software Engineer в Exadel 10.03.2021 00:41

а почему бы не aws msk ? :)

Відповісти
Підтримати
Вуйко з Канади
Вуйко з Канади 10.03.2021 10:31

можна і msk, і kinesis. я ж спитав аргументацію, для чого іменно Kafka, а не звичайний меседж брокер? З msk не працював, а Kinesis треба самому скейлити на відмінну від sqs. Тому і питаю аргументи, зачим воно вам чи Максу там.

Відповісти
Підтримати
Oleksandr Serozhenko
Dmitry Bugay Java Team Lead 10.03.2021 21:53

Ты не поверишь, но я сейчас как раз на таком охуительном проекте :(
Да, все, ВСЕ, даже небо, даже аллах, написаны на кафке. Это п****ц, ад и изгаиль.
На кафке написали даже слой, эмулирующий хттп, чтобы не использовать хттп.
*блюющий смайл*

Відповісти
Підтримати
anonymous
anonymus ps 09.03.2021 20:19

Ещё нужны микросервисы, без них никак

Відповісти
Підтримати
Max Melnyk
Sergey Lysak T/T Lead 09.03.2021 15:37

типичная и обычная задача для РСУБД
Проектировать — от данных, а потом брать бекенд что лучше всего знаете (вы+команда)
Основная нагрузка все равно будет на БД
Если сделаете наоборот, от ORMа, DDD и т.д. — почти гарантировано нарветесь на много боли, когда вся эта объектно ориентированная красотень начнет безбожно измываться над БД и вам все равно придется, уже мучительно — оптимизировать.

NoSQL вам не помогут, особенно если не делали на них реальных проектов.
А по тому как добиваться от РСУБД пристойных результатов — тьма материалов, так что если и не очень знаете сейчас — сможете добрать информации, про кластера, репликации, шардирование с партицированием, и т.п..

По озвученным вами цифрах потянет и MySQL/MariaDB

Если работали с PostgreSQL, или уверены что надо освоить и даст выгоды — берите ее.

Відповісти
Підтримати
Alex 09.03.2021 15:41

но тут важно отметить, что в данной задаче акцент сделан на эффективное чтение, а не обновление данных. Поэтому можно узучить паттерны доступа к данным, и спроектировать на nosql эффективное решение (правда, нравится комментарий

NoSQL вам не помогут, особенно если не делали на них реальных проектов.

)

Відповісти
Підтримати
Sergey Lysak
Paul Loyanich CTO в loyanich.com 09.03.2021 15:50
спроектировать на nosql эффективное решение
К этому «счастью» будут идти запросы на разные диапазоны дат.

Какое-то двоякое чувство. С одной стороны, как в анекдоте:
— Хорошо...
— Что же тут хорошего, доктор?
— Хорошо, что это не у меня.

А с другой — вы серьезно? Эффективное решение GROUP BY для 20 mln records на NoSQL? Ну нельзя же вот так...

Відповісти
Підтримати
Alex
Sergey Lysak T/T Lead 09.03.2021 15:51
но тут важно отметить, что в данной задаче акцент сделан на эффективное чтение, а не обновление данных.

тут важно отметить — что типичная история — тормоза по «пересчету цен» может класть чтение на лопатки

ТЗ на озвученную задачу наверняка превысило бы десятки страниц.
Только телепатировать можно по той паре предложений что озвучено

Но телепатировать лучше будет тот — кто варится в этом домене.
Я всю жизнь варюсь в таких задачах.
Поэтому телепатирую — там будет «пересчет цен»!
А читать когда схема это учитывает — РСУБД умеет прекрасно
Как я говорю на этапе анализа — покажите ваши отчеты. Тогда и становится ясно, какая схема нужна.

Был бы свободен — может выслал бы топикастеру свое резюме в приват :)

Відповісти
Підтримати
Alex
Alex 09.03.2021 17:08

пересчет цен задача сложная, но в данном домене она может иметь приемлимую латенси

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 09.03.2021 17:16

да, вероятность ниже чем «пересчитать прайсы для дистрибьюторов с учетом пред(!)последних цен поставщиков, ..., ...,»

но я об том — что бОльшая часть того что нужно будет по бизнес логике — осталась за кадром. в топике можно сказать — информации 0,0.

можно только увидеть домен — "екомерс"/"склады"/"опердени«/... — финансово-экономическое ПО, «энтерпрайз».

а это — РСУБД, если не хочется чего-то странного.
и потом, если понадобится — можно сбоку и монгу прикрутить. Больших сложностей не будет, вынести часть данных в нее, встречал такие решения, вполне одобряю, бывает полезно.
но если вначале «монгу», то у меня уже выкристолизовались эти постоянные муки многих. Недавно и в статьях на доу «Ошибки архитектуры» они были упомянуты. годами одна и та же история.

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

Відповісти
Підтримати
Alex
schwarzlichtbezirk 09.03.2021 17:39

Можно юзать ArangoDB, это уже вполне зрелая смешанная БД — реляционная/nosql/графовая. Для работы как с реляционной там есть AQL — аналог SQL, там кардинально решена проблема инъекций, через разделение декларации запроса и его данных. Кроме того, при изменении данных, запрос остаётся прежним.

Відповісти
Підтримати
Sergey Lysak
Sergey Lysak T/T Lead 09.03.2021 18:29
Можно юзать ArangoDB, это уже вполне зрелая смешанная БД — реляционная/nosql/графовая

можно конечно, хотя я о такой и не слышал.
но думаю да, можно.

нафуя — вопрос только себе задать. и хоть свою БД пиши, тоже — можно :)

там есть AQL — аналог SQL

аналоги SQL есть почти в каждой БД.

вопрос ведь не столько в языке работы с данными, а сколько — в возможностях движка БД.

там кардинально решена проблема инъекций

а это — «проблема»?
какая позиция этой проблемы в списке проблем в домене?

Відповісти
Підтримати
schwarzlichtbezirk
schwarzlichtbezirk 09.03.2021 13:47

Абсолютно пофиг, любой стек подойдёт. Можешь выбрать Go+Mongo.

Відповісти
Підтримати
Paul Loyanich CTO в loyanich.com 09.03.2021 15:15
Mongo

Вы пробовали Mongo на 22 млн. записей с динамическими запросами?

Відповісти
Підтримати
schwarzlichtbezirk
schwarzlichtbezirk 09.03.2021 15:29

Любая из десятка популярных баз данных с объёмами, коррелирующими с объёмами оперативной памяти, то есть в несколько десятков гигабайт, будет работать одинаково по производительности. Дальше зависит от ряда нюансов, но в несколько гиг уложится любая база, кроме тех, куда записывают какие-то поточные данные вроде показаний с группы датчиков. Если например вытянуть всю переписку с фейсбука, то уложится.

Відповісти
Підтримати
Paul Loyanich
Sergey Lysak T/T Lead 09.03.2021 15:44
Любая из десятка популярных баз данных с объёмами, коррелирующими с объёмами оперативной памяти

кроме объемов потребляемой памяти есть еще и заточенность БД под вид действий над данными.

Как только звучит

с ценами на каждый ...
История этих записей должна храниться т.к. и цены ... и «покупки» ...
Плюс к ценам могут применяться скидки

то это считай сразу, не глядя — РСУБД. Именно под это они исторически заточены. Причем так заточены — что позволяют решать задачи неизвестные на момент даже не старта, а запуска в прод.

Этих «Плюс к ценам» бизнес досыпет еще в процессе эксплуатации больше чем было озвучено.
И непредсказуемых даже самому бизнесу.
«У маркетологов — буйная фантазия!», как я говорю.

Если например вытянуть всю переписку с фейсбука,

а переписка с фейсбука — это сооовсем другие по своей структуре данные чем цены-покупки-скидки. а главное совсем другой — набор операций над ними.

Відповісти
Підтримати
schwarzlichtbezirk
Sergey Lysak T/T Lead 09.03.2021 15:57
MongoDB ж, якщо не помиляюсь, використувує B-tree і індекси для своїх запитів, як і будь-яка реляційна бд.

що не робить її — реляційною БД

А ще, РСУБД найкраще з всіх працюють з — числами.

Як я кажу РСУБД — то статична типізація, з її перевагами і недоліками
а монга — то дінамічна, з її недоліками та перевагами.

Тобто, робить це приблизно так саме

ну, приблизно так само, то нехай буде приблизно так само :)

Відповісти
Підтримати
anonymous
Paul Loyanich CTO в loyanich.com 09.03.2021 15:44
объёмами, коррелирующими с объёмами оперативной памяти
будет работать одинаково по производительности

Это не совсем верно, но спасибо за ваш ответ.

Відповісти
Підтримати
schwarzlichtbezirk
Paul Loyanich CTO в loyanich.com 10.03.2021 19:51

Тоесть вот та ситуация из топика, когда надо выбрать количество максимальных вхождений и периодичность максимальных значений нужного поля, для MongoDB не проблема, так?
Я просто давно присматриваюсь, но как-то оно не заходит даже на маленьких объемах. Разве что документы хранить. Вот и думаю, может я что-то не так делаю.

Відповісти
Підтримати
Vadim Kopanev
Vadim Kopanev Architect 10.03.2021 23:45

так. мб ты пользоваться как реляционной пытаешься просто вот и не заходит

Відповісти
Підтримати
Paul Loyanich
Ярослав Характерник Golang Developer в DocHQ 09.03.2021 12:53

Booking на одній з конференцій розповідали про свій стек, захочете знайдете на YouTube

Відповісти
Підтримати

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.