Как стать автором
Обновить

Комментарии 10

Так, например, Facebook для хранения данных использует MySQL, а Instagram построен на базе Cassandra. Вряд ли разработчики этих приложений заполняли такие таблицы. Можно лишь догадываться, что Марк Цукерберг выбрал полноценную реляционную модель, заплатив за это необходимостью прикладного шардирования, в то время как Кевин Систром заложил масштабирование средствами платформы, пожертвовав удобством доступа к данным.


Можно еще кое-что сказать. Когда Facebook начинал Cassandra еще не было, так что Цукерберг, действительно, не мог занести ее в таблички.

Более того, именно в Facebook разработали Cassandra:
Avinash Lakshman, one of the authors of Amazon's Dynamo, and Prashant Malik initially developed Cassandra at Facebook to power the Facebook inbox search feature


Но это так, мелочь. В целом — интересная статья, особенно в плане «адвокат дьявола, корпорации, презентация».
Спасибо за уточнение!
Эх, не было на господина Цукерберга 44-ФЗ. Кассандру он написал, ишь…
:)
Что лучше – Oracle или Redis

И где ответ? Или это типичная накрутка количества просмотров? За это — однозначный минус.

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

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

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

Сами-то как думаете – существует корректный ответ на этот вопрос в общем случае?

Ну и дурачки-начальники купятся.

Если ваши начальники – дурачки, то скорее всего, проблема не в них.

На самом же деле обоснованность подхода ложная. Накидать кучу параметров в табличку несложно

Это всего лишь говорит о том, что вы не понимаете, о чём пишете.
Безусловно, базы данных сравнивать таким образом бессмысленно.
Но представьте себе, что у вас есть какие-то достаточно сложные системы. Ну, например, «Периферия благотворительности», «Старый Посейдон» и «Трио-хард». В принципе, из общих соображений обычно понятно, какая именно система справится с вашей конкретной задачей лучше всего. Но нередко бывает так, что попытка формализовать «общие соображения» по описанной методике приводит к неожиданным результатам.

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

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


Статья, действительно, освещает вопросы, находящиеся на стыке бизнеса и разработки.

Но ведь даже «чистому» разработчику она может пригодится. Вот, допустим, хочется использовать/изучить что-то новое/интересное, как убедить в этом руководство, да чтобы еще и выделило ресурсы на покупку/изучение?

Статья в помощь. Вполне себе расширение «горизонта», можно ее рассматривать через призму soft skills.
Неоднократно составлял такие таблицы — вот только цель была не «выбрать платформу», а «обосновать выбор платформы». Удачный подбор критериев и весов творит чудеса :)

Предложенная техника представляет интерес если веса определяют одни люди, а оценивают другие — причем независимо друг от друга. Тогда есть какая-то объективность в этом процессе и результат может быть неожиданным.
Вот, сразу видно опытного человека :))

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

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

С учётом того, что история не знает сослагательного наклонения и как идут дела в паралельной вселенной не узнать — ну чем этот выбор лучше выбора, который делают в пет-проектах? Это только ВИДИМОСТЬ.

Хм.
Конечно, СУБД так никто не сравнивает, ибо их сильные и слабые стороны хорошо известны. Как правило, сравнению подлежат платформы, решающие какую-либо прикладную задачу.

То есть этот инструмент применяется для таких систем, которые с пет-проектами действительно живут в параллельных вселенных.

Статью можно сравнить с инструкцией по выбору карьерного экскаватора на примере лопат. Выбор лопат баз данных в пет-проектах и в параллельной вселенной практически не отличаются.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории