Да это понятно. Но такое использование уже не будет общей практикой...
Проектирование сущностей, сервисов и репозиториев
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Проектирование сущностей, сервисов и репозиториев
Так мы и не хотим чтобы service locator был общей практикой.
Нравится Yii? Давайте сделаем его лучше!.
Re: Проектирование сущностей, сервисов и репозиториев
ACID не всегда работает. Представьте сайт бронирования путешествий. Необходимо забронировать билет на самолет, гостиницу и такси в рамках одного бизнес-процесса. Сделать атомарно такое невозможно. Используют Saga pattern. Большинство бизнес-процессов в нашем мире не атомарны и для людей это нормально, соответственно нормально и для модели бизнес-процесса.
Не сдулся. Для распределенных систем не работает ACID и JOIN из классических для PHP рсубд. Убираем это и остается объектно-реляционное несоответствие и ноль преимуществ. Используют потому что так учат книги/курсы, а по другому не умеют/не знают.
Re: Проектирование сущностей, сервисов и репозиториев
По тому что вижу, этот "Saga" https://blog.couchbase.com/saga-pattern ... ices-part/ это https://martinfowler.com/eaaDev/EventSourcing.html которое доказало свою нереальную сложность, по крайней мере в моей практике я таким не страдаю. Также ты наверно не до конца понимаешь, что такое "распределение". В этой Saga есть понятие "centralized service", по сути какая-то одна штука которая все равно будет ОДНА и будет разруливать то, что делает база данных, только в Х-раз дольше из-за криворукости + теряется целостность, т.к. событие уходит в очередь - когда очередь переполняется то тот бизнес сложит лапки.
Если нужны кластеры данных - для этого есть кластеры данных. Понимаешь? Пример https://www.mysql.com/products/cluster/
в отличии от текущего состояния ИТ сферы, раньше в этом поле работали професионалы, а не тупые хипстеры, которые выдумывают "прикольные" слова быстрее, чем успевают их запоминать своими одноклеточными мозгами. И это печаль
Насчет ACID - это Atomicity, Consistency, Isolation, Durability
Существует примерно 4 уровня изоляции. Есть разный подход репликаций и т.д.
ACID никаким боком не относится к NoSQL. Это 2 разные технологии. Они не взаимоисключающие. https://docs.mongodb.com/manual/core/transactions/
Но я не спорю, для дерьма вроде твитера или фейсбука, где потеря тупых комментариев ничего не означает, можно и блокнот использовать с побитовым чтением.
вот примерный разбор twitter https://www.8bitmen.com/what-database-d ... deep-dive/
как видишь, для хранения денег и твоих персональных данных (которые они потом продадут) используется MySQL, а для всякого пользовательского дерьма - всё что только угодно, т.к. это не имеет никакой ценности (к слову, в MySQL можно отключать изоляцию, врубить кеш на 90% памяти и будет та же тема, только минус будет в размере запроса и JOIN, потому и используют подход с хеш-ключами, т.к. это проще для разработчика и для сети)
Касаемо всякой фигни вроде couchDB WakandaDB myMegaCoolDB и остальной ерунды - главное не забывать проговаривать слова "highload" и "microservice", без них не по фен-шуй получается и не так круто ездить по ушам лохов.. потом клиенты упираются - "хочу mongoDB - слышал она быстрее", ну ок, уже выгребает из-за плохого индексирования по полям
п.с.
в общем, моя твоя не понимать. Давай пример, где ты используешь "Saga pattern" - сколько миллионов пользователей/заходов и т.д.? Или ты на 1.5 инвалидах это применяешь? Я с сайтами до 100к пользователей работаю, чтобы понятней было
п.п.с.
https://nickcraver.com/blog/2016/02/17/ ... 6-edition/
Если нужны кластеры данных - для этого есть кластеры данных. Понимаешь? Пример https://www.mysql.com/products/cluster/
в отличии от текущего состояния ИТ сферы, раньше в этом поле работали професионалы, а не тупые хипстеры, которые выдумывают "прикольные" слова быстрее, чем успевают их запоминать своими одноклеточными мозгами. И это печаль
Насчет ACID - это Atomicity, Consistency, Isolation, Durability
Существует примерно 4 уровня изоляции. Есть разный подход репликаций и т.д.
ACID никаким боком не относится к NoSQL. Это 2 разные технологии. Они не взаимоисключающие. https://docs.mongodb.com/manual/core/transactions/
Но я не спорю, для дерьма вроде твитера или фейсбука, где потеря тупых комментариев ничего не означает, можно и блокнот использовать с побитовым чтением.
вот примерный разбор twitter https://www.8bitmen.com/what-database-d ... deep-dive/
как видишь, для хранения денег и твоих персональных данных (которые они потом продадут) используется MySQL, а для всякого пользовательского дерьма - всё что только угодно, т.к. это не имеет никакой ценности (к слову, в MySQL можно отключать изоляцию, врубить кеш на 90% памяти и будет та же тема, только минус будет в размере запроса и JOIN, потому и используют подход с хеш-ключами, т.к. это проще для разработчика и для сети)
Касаемо всякой фигни вроде couchDB WakandaDB myMegaCoolDB и остальной ерунды - главное не забывать проговаривать слова "highload" и "microservice", без них не по фен-шуй получается и не так круто ездить по ушам лохов.. потом клиенты упираются - "хочу mongoDB - слышал она быстрее", ну ок, уже выгребает из-за плохого индексирования по полям
п.с.
в общем, моя твоя не понимать. Давай пример, где ты используешь "Saga pattern" - сколько миллионов пользователей/заходов и т.д.? Или ты на 1.5 инвалидах это применяешь? Я с сайтами до 100к пользователей работаю, чтобы понятней было
п.п.с.
https://nickcraver.com/blog/2016/02/17/ ... 6-edition/
Re: Проектирование сущностей, сервисов и репозиториев
Можно и обратное сказать. Профессионалы из тех же Twitter и иже с ними для таблиц, значений, документов, графов, объектов, поиска и статистики используют специально для них придуманные и оптимизированные табличные, key-value, документные, графовые, объектные, поисковые и колоночные БД. И только "одноклеточные" SQL-щики на всё готовы, чтоб только из мантры "транзакции ис каропки" во все места впихнуть SQL и выгребают обходы графов. Та же печаль, только в профиль.uEhlO4a писал(а): ↑2019.08.28, 12:46 раньше в этом поле работали професионалы, а не тупые хипстеры, которые выдумывают "прикольные" слова быстрее, чем успевают их запоминать своими одноклеточными мозгами. И это печаль... Касаемо всякой фигни вроде couchDB WakandaDB myMegaCoolDB и остальной ерунды - главное не забывать проговаривать слова "highload" и "microservice", без них не по фен-шуй получается и не так круто ездить по ушам лохов.. потом клиенты упираются - "хочу mongoDB - слышал она быстрее", ну ок, уже выгребает из-за плохого индексирования по полям
Re: Проектирование сущностей, сервисов и репозиториев
ElisDN,
ха-ха. твои аргументы норм работают при разводе недалеких людей псевдокурсами, но вот в реальном мире всё совсем по-другому.
Это твое "Профессионалы из тех же Twitter и иже с ними для таблиц, значений, документов, графов, объектов, поиска и статистики используют специальн.." вообще что-то непонятное. Какие графы? ты о чем вообще? GraphQL не имеет ничего общего с базой данных, и если в какой-то момент один с хипстеров занес им FlockDB , то он с такой же скоростью оттуда и уехал. Это чтобы ты понимал https://github.com/twitter-archive/flockdb
"обходы графов", ха-ха. жги еще!
ха-ха. твои аргументы норм работают при разводе недалеких людей псевдокурсами, но вот в реальном мире всё совсем по-другому.
Это твое "Профессионалы из тех же Twitter и иже с ними для таблиц, значений, документов, графов, объектов, поиска и статистики используют специальн.." вообще что-то непонятное. Какие графы? ты о чем вообще? GraphQL не имеет ничего общего с базой данных, и если в какой-то момент один с хипстеров занес им FlockDB , то он с такой же скоростью оттуда и уехал. Это чтобы ты понимал https://github.com/twitter-archive/flockdb
"обходы графов", ха-ха. жги еще!
Re: Проектирование сущностей, сервисов и репозиториев
кстати,
1. поисковых бд нет - есть поисковые движки, можешь почитать https://www.elastic.co/products/elasticsearch - они даже так и пишут ENGINE
2. колоночные бд - это сам придумал или кто подсказал? (п.с. а, вижу, есть ClickHouse , какая-то фигня от яндекса https://github.com/yandex/ClickHouse)
3. обьектные бд, key-value и остальной треш - это одно и тоже noSQL, то есть без конкретной схемы для данных, по сути BLOB . И они все одинаковы впринципе, за исключением поддержки транзакций и типов репликаций. ха-ха
аминь
1. поисковых бд нет - есть поисковые движки, можешь почитать https://www.elastic.co/products/elasticsearch - они даже так и пишут ENGINE
2. колоночные бд - это сам придумал или кто подсказал? (п.с. а, вижу, есть ClickHouse , какая-то фигня от яндекса https://github.com/yandex/ClickHouse)
3. обьектные бд, key-value и остальной треш - это одно и тоже noSQL, то есть без конкретной схемы для данных, по сути BLOB . И они все одинаковы впринципе, за исключением поддержки транзакций и типов репликаций. ха-ха
аминь
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Проектирование сущностей, сервисов и репозиториев
Ну вот... получилась ещё одна монстротема обо всём и сразу с холиваром. Прикрываю. Давайте общаться более сфокусировано.
Нравится Yii? Давайте сделаем его лучше!.