Pull to refresh
50
Karma
0
Rating
Дмитрий @StraNNikk

Python / PHP / JavaScript developer

  • Followers 21
  • Following 22

Аналитический движок Amazon Redshift + преимущества Облака

Ну есть кейсы, когда допустим базой пользуются ребята из отдела аналитики. И пользуются они редко, и тем более из консоли, да и вообще куда им спешить — могут и подождать.
В моем кейсе база нужна, чтобы строить графики/таблицы для пользователей-кастомеров, и тормозить каждый HTTP-запрос веб-сервера на 4-5 секунд как-то совсем не комильфо. Каждая колонка в таблице — это фильтр в интерфейсе. Фильтров много, иногда делаются джойны, параметры запросов все разные. «Прогреть кэш» в данном случае не видится возможным

Аналитический движок Amazon Redshift + преимущества Облака

При прочих равных Vertica будет дороже, но я серверами не занимаюсь и деталей не скажу. Плюс само собой поддержка сложнее — редшифт из коробки одной кнопкой, а кластер вертики нужно разворачивать + это должно быть минимум 3 ноды для обеспечения кворума.
Но с другой стороны Vertica как мне кажется в функциональном плане намного лучше (тут оговорюсь, что я смотрю со своей программистской колокольни). Вот взять хотя бы драйвер для питона — у редшифта драйвер появился только полгода назад, а до этого для коннекта предлагали использовать постгрешный psycopg2. Всякие ошибки и прочие вещи для Vertica гуглятся проще, ну и в целом довольно большое комьюнити.

Аналитический движок Amazon Redshift + преимущества Облака

Это конечно все здорово, вот только у Redshift есть на мой взгляд супер-большой минус, который ставит на этой БД крест по сравнению с аналогами — необоснованно долгое время компиляции запроса. То есть даже простой запрос при первом запуске может выполняться 4-5 секунд, что ИМХО ну совсем несерьезно. Вот тут кстати подробно описано: medium.com/@pingram/redshift-code-compilation-977143576e89. На моём проекте вся инфраструктура на амазоне и казалось логичным взять RedShift для аналитики, но в итоге решили использовать Vertica — ни о чем не жалею.

Go vs Python. Виталий Левченко

Сравнение ну такое себе. Никто не спорит что Go быстрее питона, вот только мериться миллисекундами — это очень узкая ниша. В большинстве случаев ребятам из бизнеса важно, чтобы фичи делались в срок, а ребятам из разработки — чтобы код было легко читать и поддерживать. Для этого в питоне всё есть. Вот взять например Джанго — хороший фреймворк, есть все из коробки, полно батареек, миллион готовых решений. Где это все в Go? Да, asyncio наверное уступает в скорости Go, вот только если у тебя вся бизнес-логика на Python, то тащить новый язык ради одной-двух задач смысла нет. Я не спорю, что есть ниша — где выбор Go однозначен. Вот только это не значит, что это серебряная пуля он всех проблем.

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

Мне одному кажется, что проблема высосана из пальца, а статья — просто сплошное нытье и негатив? Тут достается не только мифическим «злобным менеджерам», но даже жене и детям.
Автору:
1. обратиться к психотерапевту
2. найти коворкинг/снять квартиру для работы
3. пересмотреть приоритеты в жизни, найти пару хобби, не связанных с IT. Желательно что-то спортивное (бег, волейбол, плаванье)
4. возможно поменять работу, благо вариантов на рынке — предостаточно. То что описано в статье, может и встречается, но точно — не всегда и не везде, полно продуктовых компаний, которые готовы жертвовать скоростью в пользу качества. Другое дело, если ты всё делаешь в последний момент, а вместо работы строчишь на хабре статью как у тебя все плохо — разве это потому, что менеджеры плохие?

Почему понадобилось разработать «русский дропбокс»

Почему вы не доработали NextCloud (OwnCloud) пользы от вас было бы больше

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

E2E шифрование

в данного рода решениях — это сразу ставит крест на юзабилити. хотите e2e — пользуйте BitTorrent Sync.

Почему не все так просто с MongoDB

>ReadPreference.SECONDARY_PREFERRED не значит, что «если мастер недоступен, то читать с slave», но значит, что мы всегда позволяем читать с него.

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

>Затем, что если остановка инстанса не закрывает коннект (я такое читал на их форуме) по причинам/особенностям организации сетевого стека AWS,

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

>А какого волшебного поведения вы в этой ситуации ожидали?

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

Почему не все так просто с MongoDB

>А зачем ReadPreference.SECONDARY_PREFERRED, как оно вообще относится к отказо-устойчивам write?

потому что read тоже зависает. чтобы он не зависал при гибели мастера нужно чтобы он читал с secondary

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

зачем? мне интересна именно смерть инстанса а не смерть процесса. Смерть процесса это как раз-таки случай не такой частый

>Ну и очевидно, что и без всякой поддержки в драйвере это решается элементарно, созданием DBObject (или что там вместо него в питоне) вне цикла, и запись с одним и тем же _id не пройдет.

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

>Тут какая-то путаница. Эти 5 секунд не таймаут на запрос, но таймаут на коннект. И если запрос выполняется даже 10 минут, драйвер его не сбросит, во всяком случае нормально написанный драйвер.

нет, на коннект как раз-таки есть свой таймаут. он называется connectTimeoutMS: api.mongodb.org/python/current/api/pymongo/mongo_client.html#pymongo.mongo_client.MongoClient

Почему не все так просто с MongoDB

Это зависит от задачи, можно наделать тестов где mysql будет проигрывать, например поиск в массивах, вычерпывание очереди, upsert, sparse, плавающие размеры данных и т.д.
Тут например монга обошла в 20-100 раз mysql.
Тесты тестам рознь. Если тестировать БД что называется «из коробки», то грош цена таким тестам. В той статье, что вы привели, помоему так и есть. Особенно судя по вот этому абзацу:
>Use case #1: Insertion of millions of records in parallel:

>The winner in this use case is MyISAM engine. MyISAM doesn’t neither support foreign key constraint nor transactions (unlike InnoDB). MyISAM index works good in insertion operation given that the record size will be changed, but it will be bad in case of delete/update operation.
То есть люди явно не настроили параметр innodb_flush_log_at_trx_commit в конфигах для InnoDB. Но казалось бы и пофик. Пусть даже этот тест правдив. Еще раз хочу сказать, цель данной статьи — не сказать, какая MongoDB плохая, а MySQL такой весь из себя хороший. Цель — поделиться мнением, когда MongoDB можно использовать, а когда могут возникнуть сложности.

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

Почему не все так просто с MongoDB

1. Ещё раз, DB Level Lock был пофикшен в MongoDB 2.2 ещё в далёком 2012 году.
У меня складывается ощущение что вы не смотрели ссылку, которую сюда же сами и написали. Там написано «MongoDB 2.2 increases the server’s capacity for concurrent operations with the following improvements: DB Level Locking, Improved Yielding on Page Faults»
В MongoDB 2.2 global lock был переведен с уровня процесса mongod на уровень базы. Плюс добавили «приспускание» лока во время долгих операций (аля update/delete). Ни о каком фиксе и речи не идет. Он как был так до сих пор и есть. Просто сужают область — сначала был процесс mongod, потом сделали на уровне БД. В MongoDB 3.0 сделали на уровне коллекции.

WiredTiger пока не по умолчанию исключительно по одной причине: чтобы разработчики не боялись обновляться на 3-ю версию.
Сомневаюсь. Баги на багтрекере говорят об обратном

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

Почему не все так просто с MongoDB

1. То что в Mongo 3.0 MMAP лок на уровне коллекции, а не на уровне базы — это не сильно спасает. А про WiredTiger в плане производительности говорить о каком-то прорыве еще рано. Да он в каких-то кейсах он быстрее MMAP, но реляционным БД продолжает проигрывать. Вот тут например пишут, что у WiredTiger медленный поиск по ключу, потому что он не может поместить индекс в память. Совсем не good.

2. Даже если проект делается с нуля — использовать ли WiredTiger или не использовать — это большой вопрос. WiredTiger — если что, еще даже не движок по умолчанию. Если посмотреть багтрекер 10gen, то в WiredTiger много всего интересного. Например, вот:
jira.mongodb.org/browse/SERVER-20204
или вот:
jira.mongodb.org/browse/SERVER-17456
Вы с такими багами пойдете в продакшен? я вот что-то сомневаюсь.

3.
смигрировать на WiredTiger можно очень быстро

Начнем с того, что данные надо мигрировать через backup-restore. Это процедура совсем не быстрая Вот у меня есть база 2.6 на 20млн нод активных данных с двумя шардами и репликацией. Запись идет постоянно, чтение тоже постоянно.
Вы думаете я рискну взять и обновить базу только потому что вышел новый движок? :-) Да даже если бы и не надо было делать backup-restore обновление продакшен базы с одной мажорной версии на другую черевато проблемами. А уж зная MongoDB и как ребята по стартаперски рубят обратную совместимость…

Почему не все так просто с MongoDB

Мне кажется вы как-то поспешно делате выводы, не прочитав пункт про Global lock. Там говорится и про 3.0 и про WiredTiger в том числе

Почему не все так просто с MongoDB

Да, точно. С 3.0 блокировка на уровне коллекций:
docs.mongodb.org/manual/release-notes/3.0/#mmapv1-concurrency-improvement
MMAPv1 Concurrency Improvement
In version 3.0, the MMAPv1 storage engine adds support for collection-level locking.

Как-то упустил это из виду. Видимо слишком увлекся релиз нотисами про WiredTiger.

Почему не все так просто с MongoDB

Дико извиняюсь. Конечно же опечатка.

Почему не все так просто с MongoDB

ok! спасибо за совет — учтем.

Почему не все так просто с MongoDB

Почему эксепшен это проблема?

Потому что эксепшен в данном конкретном случае не гарантирует, что запись не прошла — она могла пройти, а погла не пройти. write concern здесь вообще не при чем
emptysqua.re/blog/save-the-monkey-reliably-writing-to-mongodb
jira.mongodb.org/browse/PYTHON-197

Почему не все так просто с MongoDB

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

Да, я понимаю, что процесс не быстрый. Но как вариант решения — сгодится

Почему не все так просто с MongoDB

Вы не совсем меня поняли, да и наверное я объяснил не совсем правильно. Все почему-то набросились на 15ть секунд таймаута, хотя это тут вообще дело 10ое.

Основная проблема в эксепшенах типа AutoReconnect. Эти эксепшены происходят из-за проблем с сетью, не важно работаете ли вы на репликсете или шардированной конфигурации или же на одном сервере монги без ничего. Т.е. если драйвер pymongo в какой-то момент работы не получает ответ от сервера, то он райзит такой эксепшен. Один из частных случаев, как это воспроизвести — это отрубание primary в репликсете из 3х машин.

Проблема pymongo (и возможно MongoDB тоже) в том, что он не может проконтролировать, добавился ли документ в момент insert-а или же нет. Т.е. вы должны контролировать это сами в своем коде.

Почему не все так просто с MongoDB

не, ну я к тому, что для начала надо понять почему нельзя сделать нормальный ресторе. Т.е. локализовать проблему — т.е. это проблема утилиты mongorestore или проблема схемы данных или проблема что дамп при помощи утилиты mongodump делается как-то неправильно. Т.е. один раз руками расковырять, разобраться, решить проблему, а потом автоматизация и пр.

Information

Rating
Does not participate
Location
Нижний Новгород, Нижегородская обл., Россия
Date of birth
Registered
Activity