Блог Андрея Смирнова

Прочитал интервью Бьерна Страуструпа для австралийского ComputerWorld. В этом интервью ему задают вопрос:

Do you have any advice for up-and-coming programmers?

Мне кажется, ответ на данный вопрос формулирует то самое, к чему должен стремиться любой программист. Итак, далее мой вольный перевод на русский:

Можете что-то посоветовать начинающим программистам?

Изучайте основы программирования: алгоритмы, архитектуру машин, структуры данных и т.д. Не копируйте слепо подходы из одного приложения в другое. Вы всегда должны знать, что вы делаете, быть уверенными, что ваша программа работает, и твёрдо знать, почему она работает. Не думайте, что вы можете предсказать, какой будет индустрия программирования через 5 лет и чем именно придётся заниматься вам, поэтому учитесь более общим и полезным приёмам и подходам. Старайтесь писать код, который лучше, код, который больше соответствует вашим принципам программирования. Работайте так, чтобы программирование в большей степени было профессиональной деятельностью, а не низкоуровневым «хакерством» (программирование – это и ремесло, но не только ремесло). Учитесь на классике в области разработки и с помощью лучших книг, не надо полагаться на «how to» и документацию в онлайне – она недостаточно глубоко затрагивает вопросы программирования.

Начало серии постов здесь. Продолжаем разбираться с этим вопросом.

Проблема №3. Одного мемкеша мало

Если сайт большой, данных много, кешей тоже много, в один memcached физически не умещаемся. Пожалуйста: создаем кластер мемкешовых серверов, хешируем ключи для определения номера сервера, на котором ключ должен храниться. Всё вроде бы хорошо до тех пор, пока эти сервера не начинают падать или с ними не начинает теряться сетевая connectivity (что легко происходит, т.к. архитекутра кластерная, место на площадках ограничено, сервера физически разнесены, каналы забиты, ненадежны и т.п.)

Continue reading…

Все сегодня знают, что нагруженный веб-проект не может постоянно обращаться к БД с запросами, знают, что БД не выдержит. Все знают, что надо кешировать результаты. Можно кешировать сгенерированный HTML-контент, но лучше кешировать данные (результаты запросов), т.к. одни и те же данные могут отображаться разными способами (разные блоки, ответы по API, JSON, что-то еще).

Итак, мы договорились кешировать результаты запросов. Самый простой вариант – кешировать в файлах, однако если проект имеет кластерную (распределенную) архитектуру, кеши дублируются локальными для каждой вебморды (что приводит к большему числу запросов и к проблеме когерентности одного и того же кеша на разных мордах). Поэтому вместо файлового кеша в таких ситуациях используют замечательный продукт memcached.

Ну вот, мы всё замечательно закешировали, однако проблемы всё равно остались. Какие бывают проблемы и как с ними можно бороться? В серии постов на эту тему постараемся с этим разобраться.

Continue reading…

Индекс по полю в БД потенциально может ускорить SELECT операцию с условием по данному полю, может ускорить заброс вида: ORDER BY поле LIMIT 20, но индекс замедляет существенно операции изменения таблицы и т.п.

Когда нужен индекс, когда он поможет и будет использован при SELECTах? Всё зависит от селективности индекса, т.е. от кол-ва строк, которые мы получим если зададим условие

проиндексированное_поле = значение

Отличный кандидат для индексирования – селективность 1, т.е. уникальный индекс (например, id), когда по указанному значению мы найдем максимум одну запись. Хорошо, когда селективность составляет < 5% (например, поле city_id у пользователя). При этом PostgreSQL умён, он считает не селективность «вообще», а селективность в виде гистограммы по отдельным значениям поля. Т.е. если мы задаем условие вида

страна = Россия

то получим 10% записей из БД, а если условие

страна = Уругвай

то получим 2 записи, и это PostgreSQL понимает.

Так вот, если селективность плохая (получим много записей), PostgreSQL предпочтёт выполнить полное сканирование БД, не используя индекс. И такой индекс только мешает.