DurRandir

Вам не нужно никакое кэширование.
Вам нужно оптимизировать свои запросы.
«100 договоров и больше» — смешная цифра. По такому количеству любые выборки должны считаться предельно быстро, в сотые доли секунд.
Даже если тупо выбирать все сто договоров в скрипт и считать руками.

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

Вообще, задача, конечно, очень невнятно описана.
Если у вас, к примеру, проблемы с поиском, то можно прикрутить сфинкс.
В любом случае, надо сначала разобраться с причинами, а потом уже искать решение.

У вас ложная информация по поводу главной причины, которая не дает Вам использовать нормальный вариант, но не это главное. Делайте таблицы-агрегаты. Посмотрите запросы и постройте индексы. Заполняйте их данными после перевода договоров в стабильные статусы. Если у вас есть лишняя оперативка — лучше отдать ее правильно спроектированной БД, чем скармливать бесполезному в этом случае мемкешу, например.
Договора заканчиваются, периоды закрываются, эти данные становятся статикой и хорошо берутся из агрегатов. Вариант с кешем хорош при частых обращениях к одинаковым данным. Ваши пользователи чаще загружают один и тот же договор, или смотрят последовательно разные? Наверняка последнее, а вы забьете оперативку договорами, которые уже не нужны пользователю. Повторюсь — лучше забить эту оперативку индексами.

Но для общего развития изучить все, об чем выше уже рассказали — мегаполезно.

до сих пор сижу на старом QIP — счастлив (ищите qip8097.exe)
одно время сидел на rnq и r&q

Ещё можно делать так:

SELECT id FROM table WHERE id > последний_прочитанный_в_прошлый_раз_id ORDER BY(id) LIMIT N

Тогда при сканировании по индексу не придется каждый раз пропускать кучу записей, а можно будет начать сразу с нужного места.

1. Планируется ввести её локально
2. Для этого потребуется обучиться и обучить нескольких людей, что требует много времени и в данный момент не подходит из-за нехватки этого самого времени.

1. введите где хотите, ничего не мешает на сервак тянуть изменения с локального репозитория
2. для начала просто svn commit и svn update достаточно чтоб не терять времени, остальное можно постепенно учить. есть гуишные системы контроля версий, есть встроенные в иде.

Было бы желание. Хотя если вам проще тратить время на настройку того с чем справятся системы контроля версий лучше советов выше чем обучить пару людей пожалуйста. Вспомните еще этот камент когда зальете поверх файл с ошибкой и начнете вместо одной простой команды делать на много больше телодвижений на живом серваке. =)

Нет лучшего NoSQL хранилища вообще, есть под задачи, у каждого плюсы и ограничения. Redis супербыстр когда оперативки больше чем данных, иначе он часто подгружает с диска и сводит на нет скорость (если это еще не переделали), хорош для очередей сообщений, списков (встроены сортировки), всякой мелкой инфы. memcache (не memcached) самый быстрый но не флашит на диск ничего (собсвенно оттого и). memcached простейший key-value с флашем (хорош для очередей сообщений и всяких счетчиков). У последних двух особенность multiget — взять много ключей за раз работает столько же сколько и один, так что хорош для хранения «превьюшек» данных по их id, когда сортированные списки хранятся где-то еще (в редис). MongoDB не просто key-value, в ней можно хранить целые документы (пост со всеми комментариями), некий компромисс между nosql и RDBMS. Hbase уже совсем замена RDBMS, один из самых быстрых когда речь идет о IO диска, соответственно эта NoSQL для постоянного хранения стопитцот миллиардов данных. Cassandra похоже конкурент Hbase, но аутсайдер, т.к. фейсбук/твиттер от нее отказываются ;) Про CouchDB и Riak я ничего особенного не слышал (может кто дополнит — мне интересно)

Скажите, а на кой черт вам перл, если Вы на нем пишете как на баше?

$Date = `date +%d-%m-%Y-%H.%M`;
use POSIX 'strftime';
$Date = strftime('%d-%m-%Y-%H.%M', localtime);

$log = «Backup.'$DBname'.'$Date'.txt»;
Можно воспользоваться советом выше про chomp, это правильнее. А можно выкосить все переводы строк уже из собранной переменной $log, в данном случае это чуть короче:
$log =~ s/[\r\n]//g;

system «echo '$log' > temp.log»;
open my $fd, ">", «temp.log» or die «Can't open temp.log: $!»;
print $fd $log;
close $fd;

Да, это явно длиннее, но и намного эффективнее. Форкать процесс чтобы узнать дату или записать строчку в файл, это как-то совсем грустно…

> так как же тогда сделать сайт, способный выдержать высокую нагрузку?

1. делаете просто нужный функционал
2. оптимизируете
3. всё переделываете

я не знаю случаев, когда удавалось бы избавиться от шага 3. иногда он происходит раньше (в этом случае он относительно безболезненный), иногда позже (тогда очень тяжело), но он всегда будет, как бы вы ни старались всё предусмотреть.

Хех, в России и о законности :))) бугага… 6)
Теоретически модификация кода купленной программы прямо разрешена в ГК статью не помню…

Вопрос в том насколько легко удастся доказать это проверяющим, которые вас посетят, без наличия ключика…

3 дюйма, 5200 оборотов (греются и жрут меньше, скорость все равно ограничена сетью), у меня Hitachi DeskStar на 2 Тб такой в DS111j последний год работает.

И да, UPS сильно желательно.

Не брать диски из одной партии, чтобы уменьшить вероятность одновременного выхода из строя

Вы же сами пишете «при explain сама выборка не производится» и в то же самое время хотите получить результат, который может получится _только_ при выборке из БД. Вам не кажется это, как бы сказать, абсурдным?

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

Я стараюсь при разработке структуры базы придерживаться философского «никаких UPDATE'ов — только INSERT'ы». Это делает базу значительно более гибкой. Но соответственно увеличивается количество и сложность (JOIN'ы) SELECT'ов. Если есть запас по производительности, то конечно «вариант 1».

>>Правда ли что чем больше партиций тем, по идее, выше производительность но больше занимает места?

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

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

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

>> У таблицы есть «группирующие» поле
Не совсем понятно что вы имеете тут в виду. Если вы группируетесь по полю, которое является ключом секционирования, вероятнее всего вам придется сканировать весь набор записей, все секции, и первый, описанный мною случай, выигрыша в производительности тогда, определенно, не про вас. Я очень сомневаюсь что MySql способен, как оракл, параллелить выполнение стейтмента, потому и второй описанный случай выигрыша, тоже врядли о вас.

1 Стать диктатором
2 Ввести тоталитаризм
3 Упразднить свободу слова
4 Запретить интернет
5 Зомбировать население
6 Физически уничтожить политических противников
…
9000 БОЛЬШЕ НЕКОМУ ПИСАТЬ ПРО ВАС КЛЕВЕТУ И ЧЁРНО ПИАРИТЬ!!!

А если серьёзно, то никак.
Тот, кто пишет клевету, сам себя дискредитирует, просто предоставьте пруфы того, что это клевета, и вы окажетесь в плюсе.
И вообще, на тех категориях сайтов обычно размещают сообщения, как вы уже заметили, либо не совсем уравновешенные люди, либо тролли (написать гадость — сообщить неуравновешенному объекту — еда).
Это сайты для неудачников.
Нормальные люди обычно на такие сайты не ходят.

Отпишусь пожалуй о своем опыте.

Ситуация схожая, но изначально товаров нужно было 250 кпозицией. Анализ коробочных решений (который не я делал) показал, что либо коробка на таких объемах не может гарантировать быстрой работы, либо производители коробки хотят таких денег на энтерпрайз, что пилить свое дешевле. Собственно чем в настоящее время и занят.

Свое требует времени, но позволяет полностью контролировать движок и быть точно уверенным в нагрузках, которые он потянет. Кроме того гарантирует более выгодную схему модификации движка, т.е. супорт движка становиться проще как технически, так и финансово. А сапорт движка собственно и есть основная статья расхода для ПО. Что удалось получить на данный момент, так это каталог. Т.е. дерево категорий, карточки товара, админка для менеджеров (создать товар, добавить к товару атрибуты). Количество товаров не ограничено, количество и тип характеристик товаров так же не ограничено и ведется через админку (т.е. дополнительно кодить ни чего не нужно). Нагрузочные тесты показали, что при ~200 МБ ОЗУ под PHP движок держит 300 запросов/сек (при попадании в кэш страница генерится за 10-15 мс) долговременно (т.е. где-то до 25 миллионов хитов в сутки) и может держать пик в 1000 запрос, но не дольше 5 сек, потом начинаются валится 50-ые. Это при каталоге в 250 кпозиций по 10 характеристик на товар. В целом вся связка (веб сервер, субд, кэш) кушает 1-1,5 ГБ ОЗУ. При этом полная развязка данных и шаблонов, поэтому можно иметь сколько угодно вариантов верски, т.е. ни какой смеси из php+html нет.

Поэтому в нашем случае напиливание своего показывает себя оправданной стратегией. Я вот не вижу, каким образом можно было бы получить подобные показатели на коробочных решениях, пусть даже и допиленных. Потому как пилить ядро коробочного продукта нет смыла, а без его запилки архитектуру не изменить. Ну и модифицировать свой продукт все же проще, чем супортить чужое + дописывать под него модули.

Так что есть техническая подготовка, то есть смысл делать свое. В зависимости от опыта, общих требований я бы оценил данную работу месяца в три до года для одного разработчика на фултайме. Это до первого релиза. Ну а дальше стандартный супорт движка.

<?php
function destination($x)
{
	return 1/2 * exp(-$x * $x); //интеграл от распределения вероятности x * exp(-x * x), принимает на вход 0..1
}
function my_rand($min, $max)
{
	return $min + destination(random()) * ($max - $min);
}
function random() //random 0..1
{
	return mt_rand() / mt_getrandmax();
}

echo my_rand(10, 100);

Вот накатал пример. destination — это интеграл от распределения нужной вероятности вероятности (нормированная на еденицу)

В данном случае возвращаются числа по распределению Максвелла