Что почитать, что бы систематизировать и дополнить знания про MySQL?
Всем доброго времени суток.
Долгое время занимаюсь web-разработкой, использую php+mysql и т.д. Умею строить запросы, знаю как пользоваться join, использовал пару раз having на собеседованиях. Немного знаю о различиях myisam и innodb, имею небольшое представление о процедурах и краем уха слышал о триггерах.
В основном с MySQL работа ограничивалась написанием запросов.
Понимаю что нужно подтянуть много моментов, поэтому прошу совета. Чего бы почитать по MySQL, что бы вникнуть в индексы, процедуры и т.п., систематизировать и упорядочить текущие знания, но не углубляться до биографий разработчиков MySQL и слишком низкоуровневой логики?
А заодно, наверное, неплохо было бы почитать что-то подобное и по PostgreSQL.
Научись делать шардинг и использовать mysql в связке с elastic search.
Хотя бы так 1, 2
Всё идет к тому что БД будут использовать только для записи, а чтение, агрегирование, полнотекстовый поиск - полностью через elastic search и аналоги потому что так намного проще и скорость работы выше.
не вводите людей в заблуждение, никуда и никто не идет в сторону "БД только для записи" - это иррационально и решение "засунуть данные" еще куда-то далеко не проще чем просто работать с БД
Кирилл: объективно сейчас стараются читать только из кэша, тот же facebook юзает очень много кэша, тот же вк, инстаграм - потому что так проще и быстрее, т.к. с данными удобнее работать в денормализованной форме плюс бесплатный бонус в виде полнотекстового поиска и быстрого фасетного поиска. Из БД читают только то что плохо кэшируется. Хотя сейчас не редки решения полностью на memcache или полностью на elastic search, где обычная БД не используется вообще.
Конечно это больше вопрос стоимости потери данных. Но без реплик данные можно потерять и с БД.
asd111: facebook старается читать из кэша только по причине 4 милиардов rps в тот самый кэш, в любом случае запихивание данных в кэш это последнее что можно делать, т.к. гемороя оно доставляет.
В большинстве случаев использование эластика/сфинкса и прочего полностью не оправданно, т.к. все считают что на их данных какой-то там хайлоад, а на самом деле его нет, СУБД легко справится, + делают так потому что не знают что СУБД может немного больше чем строки по PK доставать, вот и городят зоопарк. Современные СУБД легко обслуживают десятки тысяч транзакций в секунду, что для большинства чуть более чем достаточно, вопрос в другом, многе могут положить сервер с 10 запросов, поэтому пытаются перенести проблемы с больной головы на здоровую, проще из БД в эластик/сфинкс
Простой
Простой
