0:31 Впечатления подкастеров от конференции Moscow Python Conf++ (немного милого оффтопа) 2:21 Идеальная база данных для проекта (Алексей Штырняев) 3:02 Идеальная база данных для проекта (Григорий Петров) 6:20 NoSQL базы данных как альтернатива 10:16 Коротко о CAP-теореме (Consistency, Availability, Partition tolerance) применительно к базам данных (подробнее см. habr.com/post/130577/) 13:29 О транзакционных и нетранзакционных базах данных и ACID (Atomicity, Consistency, Isolation, Durability) 15:37 Тип базы данных для первого проекта 18:47 Допустимо ли, чтобы пользователь видел кэшированную страницу с котиками на любимом сайте вместо актуальной 19:51 Для чего использовать кэш 21:43 Об особенностях Cassandra 23:17 Базы данных для хранения статистики (Time Series Database) и ClickHouse 24:57 Ответ на вопрос, какую базу данных выбрать джуниору
как человек судя по собеседам не дотягивающий до джуна, могу смело заявлять. Джуны должны представлять как много примерно данных будет падать в бд. так же должны понимать когда им нужна sqlite, а когда серверная реляционная бд. И тут вы ответили на главный вопрос "какую сервеную бд из реляционных использовать?". Продолжите пожалуйста тему. Расскажите какие нереляционные бд для каких ситуаций нужны? от джунов очень многого сейчас хотят. Спасибо за технический выпуск. Буду ждать следующих)
По поводу сленга. На майские праздники приехал к другу (он программист), он мне говорит, что нужно сходить на митинг и потом он будет свободен. Я в свою очередь, как человек не знающий сленга, подумал, что ему необходимо пойти на первомайский митинг (как это было в прошлом). В общем когда все разъяснилось смеху было...P.S. Григорий == Винокур. Красава, разряжает обстановку, своими еп..., жру.... и т.д
ИМХО. Для джуна, который только начал ковырять питон и особенно джангу, за глаза будет noSQL баз данных. Как помню, джанго из коробки использует сейчам SQLite и этого же для начала за глаза. Потыкаться, по мыкаться, по изучать вообще работу питона, джанги и запилить небольшой бложикю
@@lexkosha да, для большого и крупного не подойдёт. Но у нас как бы разговор для джунов и азам изучения всего этого. ОРМ джанги прекрасно работай что с SQLite что с Постгри. По факту же, Джун изменив тип БД ничего и не заметит, кроме быстродействия. А вот на начальном этапе, я считаю, это лишние знания, которые "пока что" ещё не нужны.
Ээээм, для джуна действительно много новых странных слов ))) задумался о блокнотике и последующем поиске непонятной терминологии. Под конец был интересный момент про ошибки использования баз данных. Может быть будет возможность разобрать это более углубленно? Когда лучше терзать базу, а когда эффективней использовать инструментарий python или что-то в таком роде.
MySQL прекрасен, просто нужно уметь его готовить. Postgres тоже хорошо, но под каждую задачу надо выбирать. Ваш кэп)) да, забыл: у Майкрософта супермегакрутая бд, с кучей приятных фич.
Мы используем в основном posrgresql, и очень довольны, у нас есть один проект на mysql, и кластерное решение на базе galera постоянные проблемы с падением кластера, да и sql скрипты после очередного обновления перестают стабильно работать, в общем не советую
В MongoDB проверять уникальность 2 и более полей, при том что несколько документов могут временно содержать null в одном из полей -- на уровне СУБД оказалось невозможно. В реляционных базах данных null != null, а в MongoDB наоборот. В случае если все указанные поля null, документ просто не кладётся в индекс уникальности -- поведение ожидаемое. А вот если указать одно поле, а другое оставить как null -- всё, она попадает в индекс и другую запись с такими же значениями этих двух полей добавить нельзя. Таким образом, при использовании MongoDB придётся проверять такие вещи программного в рамках Django / Flask / Pyramid / aiohttp или др. приложения. При этом, приложение у Вас может быть запущено в несколько процессов и несколько потоков, так что при конкурирующих запросах проверка может не сработать. В итоге, взял PostgreSQL, где всё привычно. Проверка на уникальность трёх полей работает ожидаемо, пока хоть одно поле не указано -- два другие поля могут содержать одни и те же значения. В моём случае, это 1) тип рабочей станции, 2) номер этажа и 3) номер места.
Тема интересная и важная для каждого джуна, но запутали так запутали) Очень странно, но общий смысл ваших аргументов в пользу PostgreSQL - "так исторически сложилось". У каждой СУБД множество плюсов и минусов. MySQL имеет множество удобных клиентов для работы с ней и установлена почти на каждом хостинге, а PostgreSQL лучше заточена под кластеры и на своей стороне может выполнять скрипты на том же самом питоне (и т.д.). Для простых задач и обучения разницы между MySQL и PostgreSQL вы не увидите. Выбирайте любую. Когда джун делает проекты сложности ToDoList -а, то кластеризация, хеширование и тем более NoSQL ему не нужны. Ему надо въехать в CRUD и научиться писать сырые запросы хотя бы с одним JOIN. А уже когда почувствует, что реляционной СУБД ему не хватает по каким либо причинам (например перестанет устраивать быстродействие), то можно и Redis и Mongo. Но настанет этот момент скорее всего не быстро.
"Редис только для кешей" - блин, ребят, не надо так. Редис, это инструмент, которым много чего сделать можно. Про монгу вообще смех и грех... Не надо так джунов дезинформировать! :-)
0:31 Впечатления подкастеров от конференции Moscow Python Conf++ (немного милого оффтопа)
2:21 Идеальная база данных для проекта (Алексей Штырняев)
3:02 Идеальная база данных для проекта (Григорий Петров)
6:20 NoSQL базы данных как альтернатива
10:16 Коротко о CAP-теореме (Consistency, Availability, Partition tolerance) применительно к базам данных (подробнее см. habr.com/post/130577/)
13:29 О транзакционных и нетранзакционных базах данных и ACID (Atomicity, Consistency, Isolation, Durability)
15:37 Тип базы данных для первого проекта
18:47 Допустимо ли, чтобы пользователь видел кэшированную страницу с котиками на любимом сайте вместо актуальной
19:51 Для чего использовать кэш
21:43 Об особенностях Cassandra
23:17 Базы данных для хранения статистики (Time Series Database) и ClickHouse
24:57 Ответ на вопрос, какую базу данных выбрать джуниору
как человек судя по собеседам не дотягивающий до джуна, могу смело заявлять. Джуны должны представлять как много примерно данных будет падать в бд. так же должны понимать когда им нужна sqlite, а когда серверная реляционная бд. И тут вы ответили на главный вопрос "какую сервеную бд из реляционных использовать?". Продолжите пожалуйста тему. Расскажите какие нереляционные бд для каких ситуаций нужны? от джунов очень многого сейчас хотят. Спасибо за технический выпуск. Буду ждать следующих)
Попробывать стоит с реляционной и ей же закончить пробовать.
По поводу сленга. На майские праздники приехал к другу (он программист), он мне говорит, что нужно сходить на митинг и потом он будет свободен. Я в свою очередь, как человек не знающий сленга, подумал, что ему необходимо пойти на первомайский митинг (как это было в прошлом). В общем когда все разъяснилось смеху было...P.S. Григорий == Винокур. Красава, разряжает обстановку, своими еп..., жру.... и т.д
ИМХО. Для джуна, который только начал ковырять питон и особенно джангу, за глаза будет noSQL баз данных. Как помню, джанго из коробки использует сейчам SQLite и этого же для начала за глаза. Потыкаться, по мыкаться, по изучать вообще работу питона, джанги и запилить небольшой бложикю
это разные вещи. мое мнение - сразу окунуться в postgres и понять что к чему. и разобраться с nosql для сравнения.
Alexandr M. Для теста и обучения на локалке мб хватит, а для норм проекта куда будешь лить траф. Не подойдёт
@@lexkosha да, для большого и крупного не подойдёт. Но у нас как бы разговор для джунов и азам изучения всего этого. ОРМ джанги прекрасно работай что с SQLite что с Постгри. По факту же, Джун изменив тип БД ничего и не заметит, кроме быстродействия. А вот на начальном этапе, я считаю, это лишние знания, которые "пока что" ещё не нужны.
Чтоб только поднять да и не много потыкать.
Ээээм, для джуна действительно много новых странных слов ))) задумался о блокнотике и последующем поиске непонятной терминологии. Под конец был интересный момент про ошибки использования баз данных. Может быть будет возможность разобрать это более углубленно? Когда лучше терзать базу, а когда эффективней использовать инструментарий python или что-то в таком роде.
Спасибо за отличную идею!
Спасибо! )
MySQL прекрасен, просто нужно уметь его готовить. Postgres тоже хорошо, но под каждую задачу надо выбирать. Ваш кэп)) да, забыл: у Майкрософта супермегакрутая бд, с кучей приятных фич.
Только жалко что на хостингах недорогих доступных джунам чаще всего вместо PostgreSQL джун встретит всеми любимую mySQL либо MariaDB )))
Artyom Vashkevich что значит недорогих? Я не встречал хостера без поддержки PG
Виртуальная машина на DO (за $5) или у российского хостинга будет стоить до 300р/мес. или меньше
Алексей Ш и что на них нет слоника😂😂😂?
lex kosha в том то и дело что есть))
Алексей Ш в точку, только коммент выше гласит о другом что его нет. Часто использую дешевые хостинга даже по 99р там есть слоник)))
Мы используем в основном posrgresql, и очень довольны, у нас есть один проект на mysql, и кластерное решение на базе galera постоянные проблемы с падением кластера, да и sql скрипты после очередного обновления перестают стабильно работать, в общем не советую
Вот бы увидеть подкаст только с Григорием!
В MongoDB проверять уникальность 2 и более полей, при том что несколько документов могут временно содержать null в одном из полей -- на уровне СУБД оказалось невозможно.
В реляционных базах данных null != null, а в MongoDB наоборот. В случае если все указанные поля null, документ просто не кладётся в индекс уникальности -- поведение ожидаемое. А вот если указать одно поле, а другое оставить как null -- всё, она попадает в индекс и другую запись с такими же значениями этих двух полей добавить нельзя.
Таким образом, при использовании MongoDB придётся проверять такие вещи программного в рамках Django / Flask / Pyramid / aiohttp или др. приложения. При этом, приложение у Вас может быть запущено в несколько процессов и несколько потоков, так что при конкурирующих запросах проверка может не сработать.
В итоге, взял PostgreSQL, где всё привычно. Проверка на уникальность трёх полей работает ожидаемо, пока хоть одно поле не указано -- два другие поля могут содержать одни и те же значения. В моём случае, это 1) тип рабочей станции, 2) номер этажа и 3) номер места.
Тема интересная и важная для каждого джуна, но запутали так запутали) Очень странно, но общий смысл ваших аргументов в пользу PostgreSQL - "так исторически сложилось". У каждой СУБД множество плюсов и минусов. MySQL имеет множество удобных клиентов для работы с ней и установлена почти на каждом хостинге, а PostgreSQL лучше заточена под кластеры и на своей стороне может выполнять скрипты на том же самом питоне (и т.д.). Для простых задач и обучения разницы между MySQL и PostgreSQL вы не увидите. Выбирайте любую. Когда джун делает проекты сложности ToDoList -а, то кластеризация, хеширование и тем более NoSQL ему не нужны. Ему надо въехать в CRUD и научиться писать сырые запросы хотя бы с одним JOIN. А уже когда почувствует, что реляционной СУБД ему не хватает по каким либо причинам (например перестанет устраивать быстродействие), то можно и Redis и Mongo. Но настанет этот момент скорее всего не быстро.
Спасибо, много ценных предложений!
У Гриши ботинки такие странные на вид
"Редис только для кешей" - блин, ребят, не надо так. Редис, это инструмент, которым много чего сделать можно.
Про монгу вообще смех и грех... Не надо так джунов дезинформировать! :-)
О, Зеленяк пришел!
Я не сам. Меня притащили...
Мы очень любим редис! И тратим время на чтение из него. А про кэши это к Григорию.