Свежие комментарии

Орейли-книги вообщем-то можно и бесплатно в сети найти :)

Но если рассматривать варианты за деньги то еще можно рассмотреть всякие членства, например Computer society дает доступ к о'рейли книжкам за стольник год вроде http://www.computer.org/portal/site/ieeecs/menuitem.c5efb9b8ade9096b8a9c...
ACM'овское членство тоже дает какой-то такой доступ (может не к орейли значит к другому паблишеру)

:) Да, можно как студент регистрироваться - полтиник экономия будет

Масштаб переделок там большой.
Но все там будем - нет никаких шансов прожить в рамках старой парадигмы (без распределенной конструкции) в ближайшие 10-20 лет.

И таки да - историй про MySQL, оптимизации которого приводят к неверным результатам что-то не слышно.

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

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

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

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

Ключевая мысль, на самом деле - производительность достигается не вылизываем тактов в каком-то алгоритме, а архитектурой. Вылизывание тактов, впрочем, тоже неплохо.

Решение задачи принципиально зависит от соотношения доступной памяти и максимального размера БД.

Если говорить о задаче типа "счетчика", с 8-байтным ключем и 20-байтными данным на современной машине, 100М записей :), то мое решение такое:

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

статически выделенная таблица указателей на "страницы", размером в величину хеша * на размер указателя. Тут у нас не возникает никакого дефицита.

"страницы" записей с одинаковым хешем, динамически выделяемые по мере добавления ключей , сортированные. 28 байт на значение. Да-да-да, тут у нас реаллок и много аллоков при добавлении записей, но я думаю ты знаешь, как это делается с практически нулевым оверхедом по памяти и производительности. Да и добавление записей-то вещь редкая, а обращение - частое.

Тут у нас уже дефицит памяти и адресного пространства в 32 битах становится существенным. Но с 64 битами на современной машине мы прекрасно вписываемся.

при изменении данных они маркируются и фоновый процесс сливает все в БД. Таким образом производительность дисков не влияет на производительность самой системы.

при дефиците памяти можем грохать таблицы, к которым давно не было обращений.

Я так делал еще в DOS :), где дефицит памяти был куда как более суровым. Программирования тут - на несколько часов, обсуждать дольше.

То что SAN - это такая job security и никого не накажут за покупку самой крутой дисковой полки/шкафа, ибо там дохрена девяток и вообще сервис-инженер приезжает через час после звонка - это все понятно. То же самое и с базами данных - то, что Oracle может просто давать неправильный ответ на запрос (при том, что по маленьким данным все тесты отличные) - никого не ипет, это Oracle, если они не смогли, то кто же?

Но это не имеет отношения к "дешевле".

А так - тебе EMC с удовольствием продаст тот же терабайтный Seagate ES.2 за 700 баксов вместо 150. Все будут довольны.

Да очевидно.
Посмотри на тех, у кого в сторадже реальный бизнес. Ну вот гугл (или амазон S3, хотя про них меньше известно). Сторадж, очевидно, самый толстый в мире, если бы SAN был бы дешевле - не было бы у них этих мульенов писюков.

WebKit-based понимают. Поэтому правильно поступать так: делать sRGB и включать профиль в JPEG.
Тогда Apple (где цвета другие) поймёт профиль и покажет всё правильно (всё же FireFox2 на MacOS -- редкость, она будет в пролёте, увы), а на винде, где sRGB -- Совсем родной IE и старые FF не поймут его, но всё равно покажут правильно.

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

На Fedora FF3 профилей не понимает

Re: > А юниксовый - собирать с lcms
Ага, подтверждаю. После этого, заработало. FF3, дистрибутивная сборка от Debian.

Набрать нужные мне терабайты сегодняшними SSD по 80GB - это будет сиотреться порнографично. :-)

Скорее всего проблема в размере записи и кластера. SQL записывает 8k страницу физически записывая 32k кластер.

Re: > Ну это же как собрать.
--enable-system-lcms (судя по configure),

Re: > Угу, проверил на Firefox3/FreeBSD - галка есть
Ну это же как собрать. Я вот собрал просто из портов, не думая, оно собралось без color management. Причем, в тех опциях, которые порт спрашивает - даже и вопроса нет такого.
Отчего галка есть, а проку от нее нету.

Про такую фигню как цветовые профили - знают то очень немногие, а понимают - еще меньше. Зато авторам книжек есть про что писать - в любой книжке по цифровому фото можно смело делать главу на 100 страниц про CMS.