Как обосновать применение реляционной БД на интервью по System Design?
Хэлоу,
Недавно сел в лужу на интервью по System Design в одном бигтехе - применил RDBMS PostgresDB для реализации одного из Use Case, попросили обосновать.
Сам Use Case не буду выписывать, чтобы не раскрывать детали интервью, но он предполагал выборку некоторых данных по PK, результат - допустим 100 записей.
Тут я немного впал в ступор - обычно чёткого обоснования требует скорее применение нереляционных БД, а тут вроде как по умолчанию получилось - по latency вписывались, гарантии самые высокие (и достаточные для Use Case), БД достаточно "стандартная".
Сказал про гарантии, предоставляемые БД (сами гарантии не перечислял, но мог бы, если бы потребовалось), также упомянул, что Use Case требует для реализации делать выборку по некоторому ключу и данная БД умеет делать такие выборки. Вскользь упомянул возможное использование документоориентированной БД, но отмёл решение как менее "стандартное".
В итоге сказали, что обосновал слабо и не рассмотрел альтернативы.
Подскажите, а как Вы бы обосновывали применение реляционной БД? (Предполагаем, что сам выбор был сделан верно :) )
ну а как тогда обосновывать, вот например "он предполагал выборку некоторых данных по PK" может говорить что тут лучше будет специализированная key-value база? Как не зная нюансов можно что-то обосновывать?
Положительный ответ на вот эти два вопроса в целом достаточное обоснование. Что-то более сложное - это надо проводить исследования, собрать прототип, провести тестирование решения, возможно даже для нескольких разных БД, сделать сводную таблицу результатов, подвести итоги исследований. Вот тогда да, будет "сильное" обоснование. "Сильное обоснование" входило в условия ТЗ? Если не входило и вы не делали - то в данном случае не вы "сели в лужу", а те, кто проводил интервью. Возможно, надо было уточнить, какое именно обоснование они хотят получить и сколько они готовы за это заплатить. ТЗ было какое? Решить конкретную задачу в определённых рамках. Вы её решили успешно? Значит, вы молодец и всё отлично.
Реляционные СУБД способны решать наиболее широкий круг задач, при этом менее требовательны к ресурсам, чем noSQL, что делает их решением по умолчанию, пока нет специфических проблем, требующих поиска специфических решений. Кроме того, реляционки более распространены, так что компании легче будет нанять и программистов и DBA для работы с ними.
Реляционные базы данных функциональнее других, обычно за это приходится платить ресурсами, но бывает не приходится.
Т.е. если под требования задачи выбранная реализация подходит, значит выбирай решение 'на вырост', так сказать подложить соломку заранее. Конечно, правило 'преждевременной оптимизации' не абсолютно, можно заранее подумать... и конечно реляционные решения обычно проще в использовании, sql язык промышленный стандарт, особенно если сравнивать no-sql решения, где api у каждого свой и переносимость околонулевая. Т.е. если выбранная реляционная база данных вдруг не подошла по функционалу, трудозатраты на перенос решения в другую будут значительно меньше, чем если то же самое делать с no-sql или не дай бог с самостоятельным решением на файлах.
И да, это не защитит тебя во всех случаях, деградация производительности или затраты на ресурсы у реляционных баз данных может оказаться фатальной, но даже в этом случае подставить подпорки из промежуточных решений может оказаться проще чем пилить что то узкоспециализированное.
С другой стороны, если не пилить велосипедов (или не брать узкоспециализированные и не улучшать их под свои проблемы), то как тогда новые технологии будут появляться?
Дополню, что на system design смотрят на твой кругозор в том числе, так что:
1. Хоть реляционка и подходит тут, но стоит также упомянуть альтернативные решения с их плюсами и минусами
2. А как же аргументация к наличию специалистов? Вполне можно аргументировать выбор реляционной базы тем, что гораздо легче найти людей, которые умеют с ней работать.
3. Ну и как уже написали - можно использовать аргумент "на вырост". Может на момент проработки архитектурного решения нам и подходит какая-то key-value или документ-ориентированная система, но это не значит, что при расширении нам будет её хватать.
Если предлагаешь только реляционную бд без рассмотрения альтернатив - это выглядит так, будто ты больше ничего и не знаешь, потому и предлагаешь просто знакомое решение/решение с которым сам умеешь работать.
