afiskon

Скорее всего вам это не нужно. Вряд ли у вас миллионы запросов в секунду и скорее всего вам нужны вьюхи и нормальные транзакции, чего вам не даст mongodb. Если на 100% не уверены, что вам для вашей задачи нужна mongodb, это скорее всего потому что она вам нахрен не нужна.

Похоже на то, что вы ищите?

MySQL - оптимизация производительности. Отличная книга.

В эти агрегированные логи как правило все равно никто не смотрит. Смотрят в мониторинги (самопальный, все лампочки зеленые - значит все ок, есть красные - значит не ок). иногда в метрики (Graphite). Если у вас какая-то бизнес-логика логируется, там обычно много кастомных требований, типа фильтрации, помержить данные из внешнего источника и тд и тп, проще свой CRUD для любой РСУБД написать.

Вот хорошая книжка по этой теме. А здесь - просто небольшая статья об оптимизации. Взгляд с высоты птичьего полета, так сказать.

У вас есть множество серверов для хранения картинок. Возможно. тех же самых, на которых работают и скрипты, не важно. Вы на этих серверах держите специальную приложеньку для заливки картинок. Когда приходит картинка, выбираете случайным образом один из серверов (держите список в MySQL/Redis/неважно), заливаете картинку, получаете обратно ссылку. В базу пишите ссылку img123.myproject.com/123/45/38475.jpg.

Если сервер дохнет, поднимаете новый, присваиваете ему имя img123.myproject.com, восстанавливаетесь из бэкапа, снова все работает. Раздавать картинки, разумеется, нужно не через приложеньку, а напрямую через nginx.

А еще для хранения картинок неплохо подходит Riak. Плюс в том, что вы получите шардинг, решардинг и репликацию из коробки и особо думать ни о чем не надо.

Мне кажется, вы для своих задач не ту СУБД выбрали. PostgreSQL щелкает такие вещи как нефиг делать - там специальные типы данных, индексы и тд. Тут кое-какие подробности на этот счет.

Relevant: eax.me/database-design

Лучше поздно, чем никогда :) eax.me/database-design

Есть несколько способов. Например, создаете таблицу с общими полями для всех типов статей, типа articles: id, slug, title, desc, type. Затем для каждого конкретного типа - таблицу с характерными для данного типа полями, article_types: id, field1, field2, ...

Или делаете полную денормализацию - в одной таблице все возможные поля, которые в зависимости от типа будут или не будут NULL.

А можно вообще сериализовывать дополнительные поля в JSON и хранить его в специальном поле.

Лучше не писать свою CMS. Но если прям очень хочется, посмотрите, как сделано в Yesod, там все очень очень правильно.

Попробуйте сделать составной b-tree индекс по a.id и a.create

Ну вообще-то при использовании нормальных фреймворков/ORM вероятность SQL Injection или например атаки с помощью XSS становится очень небольшой. Но если хочется перестраховаться, запретите прямое хождение в таблицу и работайте с ней исключительно через процедуры например, частично поможет. (Безопасность - это процесс, а не результат).

SELECT ... FROM articles WHERE slug = .... (LIMIT 1) ну и индекс по полю slug конечно же!

Бред какой-то. Используйте нормальные средства для работы с СУБД (в Perl это к примеру DBIx::Class) и все у вас будет хорошо безо всяких извращений с кодированием.

Если я правильно понял вопрос, то

SELECT id FROM table_name WHERE object_id = $OBJECT_ID AND time >= $START_TIME AND time <= $END_TIME ORDER BY time LIMIT 1

Чтобы запрос был эффективным, вам может понадобится (если таблица большая) составной индекс по object_id и time.

Скорее всего time придется взять в кавычки, смотря что за СУБД.

Я не специалист, но по-моему нельзя. Любое изменение в MyISAM таблицах приводит к блокированию всей таблицы. Если вы часто производите такие операции, возможно, вам имеет смысл перейти на InnoDB (или альтернативный движок с блокировкой на уровне строк).