Как обосновать применение реляционной БД на интервью по System Design?
Хэлоу,
Недавно сел в лужу на интервью по System Design в одном бигтехе - применил RDBMS PostgresDB для реализации одного из Use Case, попросили обосновать.
Сам Use Case не буду выписывать, чтобы не раскрывать детали интервью, но он предполагал выборку некоторых данных по PK, результат - допустим 100 записей.
Тут я немного впал в ступор - обычно чёткого обоснования требует скорее применение нереляционных БД, а тут вроде как по умолчанию получилось - по latency вписывались, гарантии самые высокие (и достаточные для Use Case), БД достаточно "стандартная".
Сказал про гарантии, предоставляемые БД (сами гарантии не перечислял, но мог бы, если бы потребовалось), также упомянул, что Use Case требует для реализации делать выборку по некоторому ключу и данная БД умеет делать такие выборки. Вскользь упомянул возможное использование документоориентированной БД, но отмёл решение как менее "стандартное".
В итоге сказали, что обосновал слабо и не рассмотрел альтернативы.
Подскажите, а как Вы бы обосновывали применение реляционной БД? (Предполагаем, что сам выбор был сделан верно :) )
ну а как тогда обосновывать, вот например "он предполагал выборку некоторых данных по PK" может говорить что тут лучше будет специализированная key-value база? Как не зная нюансов можно что-то обосновывать?
Наличие экспертизы было также мной отмечено как аргумент в пользу выбора.
Кругозор как мне видится я продемонстрировал ранее по ходу интервью - задача была намного обширнее и там были и Ceph и Elastic и Redis :) Как альтернативу для этого конкретного Use Case я вскользь упомянул Cassandra.
В общем я либо всё-таки неверно реализовал сам Use Case и интервьюер пытался меня подтолкнуть к осознанию этого, либо я всё-таки что-то важное в обосновании упустил, но пока по-прежнему не понимаю, что именно.
Положительный ответ на вот эти два вопроса в целом достаточное обоснование. Что-то более сложное - это надо проводить исследования, собрать прототип, провести тестирование решения, возможно даже для нескольких разных БД, сделать сводную таблицу результатов, подвести итоги исследований. Вот тогда да, будет "сильное" обоснование. "Сильное обоснование" входило в условия ТЗ? Если не входило и вы не делали - то в данном случае не вы "сели в лужу", а те, кто проводил интервью. Возможно, надо было уточнить, какое именно обоснование они хотят получить и сколько они готовы за это заплатить. ТЗ было какое? Решить конкретную задачу в определённых рамках. Вы её решили успешно? Значит, вы молодец и всё отлично.
Реляционные СУБД способны решать наиболее широкий круг задач, при этом менее требовательны к ресурсам, чем noSQL, что делает их решением по умолчанию, пока нет специфических проблем, требующих поиска специфических решений. Кроме того, реляционки более распространены, так что компании легче будет нанять и программистов и DBA для работы с ними.
Дополню, что на system design смотрят на твой кругозор в том числе, так что:
1. Хоть реляционка и подходит тут, но стоит также упомянуть альтернативные решения с их плюсами и минусами
2. А как же аргументация к наличию специалистов? Вполне можно аргументировать выбор реляционной базы тем, что гораздо легче найти людей, которые умеют с ней работать.
3. Ну и как уже написали - можно использовать аргумент "на вырост". Может на момент проработки архитектурного решения нам и подходит какая-то key-value или документ-ориентированная система, но это не значит, что при расширении нам будет её хватать.
Если предлагаешь только реляционную бд без рассмотрения альтернатив - это выглядит так, будто ты больше ничего и не знаешь, потому и предлагаешь просто знакомое решение/решение с которым сам умеешь работать.
Реляционные базы данных функциональнее других, обычно за это приходится платить ресурсами, но бывает не приходится.
Т.е. если под требования задачи выбранная реализация подходит, значит выбирай решение 'на вырост', так сказать подложить соломку заранее. Конечно, правило 'преждевременной оптимизации' не абсолютно, можно заранее подумать... и конечно реляционные решения обычно проще в использовании, sql язык промышленный стандарт, особенно если сравнивать no-sql решения, где api у каждого свой и переносимость околонулевая. Т.е. если выбранная реляционная база данных вдруг не подошла по функционалу, трудозатраты на перенос решения в другую будут значительно меньше, чем если то же самое делать с no-sql или не дай бог с самостоятельным решением на файлах.
И да, это не защитит тебя во всех случаях, деградация производительности или затраты на ресурсы у реляционных баз данных может оказаться фатальной, но даже в этом случае подставить подпорки из промежуточных решений может оказаться проще чем пилить что то узкоспециализированное.
С другой стороны, если не пилить велосипедов (или не брать узкоспециализированные и не улучшать их под свои проблемы), то как тогда новые технологии будут появляться?
Очень сумбурно автор описал. Многое из контекста непонятно. Вроде сам решил применить Postgres.
Ну ОК. Решил так решил.
И как по ПК можно выбрать 100 записей? Сделать 100 запросов? Или это не-ПК? Непонятно.
Вообще ни один производитель СУБД ничего не пишет про отклики. Это можно обсуждать
например в контексте приложения redis/web-server/dbms и там что-то придумывать и обосновывать.
Отклик - это сложная сумма которая состоит из множества слагаемых и не всегда БД там главная.
Вообще сама идея или само обоснование NoSQL (AWS Dynamo,. Azure Cosmos DB) идет как раз
от гарантий что вендор будет давать пропускную способность и отклик пропорционально вашей
оплате. Вы покупаете условно например какое-то количество RU (Request-Units) и все облако начинает
подстраиваться под вас таким образом чтобы соблюдать рост и независимость от размера данных.
Все что касается других (single-node, standalone) систем то они обычно быстро достигают пика
либо на диске либо на сети и после этого уже про отклик нельзя ничего говорить. Даже вкупе
с индексом все равно есть определенная деградация. И вы очень смелый человек если
сразу стали что-то стали чертить на базе реляционной системы.
Вообще если вы решили обсуждать например системную архитектуру то можно отбросить БД
и зайти со стороны философии и требований. Например лет 20 назад мы все знали что дисковая
подсистема на основе 1 магнитного диска обеспечивала скорость поиска блока в 15 мс.
Это так называемый random seek. И эта величина очень долго стоит как стена. Не
двигается особо даже для современных HDD. Механика чорт ее дери...
Для поиска любой записи в индексе вам надо сделать 4-5 seek по диску при условии что
мы диск полностью заполнили. Тоесть получается что быстрее чем 55 милисекунд мы не можем
гарантировать поиск записи по ПК для БД на магнитном носителе. Про SSD тоже можно
порассуждать. И в контексте бенчмарков в самом неблагоприятном состоянии.
Диск может быть заполнен на 99% например по размеру. Почему нет? Всяко бывает.
Вот так. Философски рассуждая мы можете вообще начать разговор. А уже какая там БД. Tarantool, Cassandra, LevelDB это уже как-бы детали к системной архитектуре.
Простой
