В Oracle, например, задается размер tablespace при создании. После надо уже извращатся, когда данные не станут влезать в этот файл.

http://docs.oracle.com/cd/B19306_01/server.102/b14220/physical.htm

А чем не подходит это?

The third option for enlarging a database is to change a datafile's size or let datafiles in existing tablespaces grow dynamically as more space is needed.

ALTER DATABASE 'DATA3.ORA' AUTOEXTEND ON NEXT 20M MAXSIZE 1000M;

и ты на мой вопрос не ответил:

ты правда понимаешь разницу между а) и б)?

AUTOEXTEND

zvonkij_fejspalm.bat

ты правда понимаешь разницу между а) и б)?

Правда.

AUTOEXTEND

zvonkij_fejspalm.bat

А подробнее?

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

У всего есть свои пределы. Еще раз, с ограничением памяти легко добиться io wait, просто потому, что кэш всегда будет дергать свежие данные с диска. Я не хочу сказать, что mmap это идеальное решение, но логично, что когда рабочий набор всегда находится в памяти, тогда нет надобности лишний раз дергать диск, тем самым, повышая производительность.

И очень странно вы рассуждаете, когда говорите, что с ограничением ОЗУ вас все устраивает, а без ограничения нет. Т.е. производительность для вас вообще особо не критична. Что вам мешает использовать для этого монго вообще не понятно, что-что, так в своп уйдет прежде всего монго и будет также дергать диск, как и в случае с ограничением по ОЗУ. Те приложения, которым требуются выделение страниц памяти из ОЗУ, а не из свопа - будут это делать спокойно. Ядро не настолько тупое, так же можно чуть менять поведение свопинга через swapness в параметрах sysctl.

P.S. Ни монго, ни другие БД не являются идеальными решения для любого спектра задач. Не нравится монго - не используйте, и не надо кичится, будто из-за того, что киянкой сложно забивать гвозди она плохая и надо всегда брать молоток или кувалду :)

А чем не подходит это?

Да, всем подходит. Можно запилить всю работу и на ASM. Только как это поможет вам с ограниченным объемом ОЗУ непонятно. Оракл точно также маппит файлы, причем более сложным алгоритмом и в критических случаях спокойно уходит в своп. Как бы школьные поделия с одним спейсом, без всяких временных таблиц, которые постоянно аллокейтятся на каждую сессию все просто. Как только дело доходит до серьезного, вам и 48гб для Ораклы покажется малым, это так, к слову, из личного опыта.

Оракл точно также маппит файлы, причем более сложным алгоритмом и в критических случаях спокойно уходит в своп.

Судя по треду, у Mongo тоже бывают такие проблемы.

в конструктивной теории прекрасно работает чуть другое определение множества.

Совсем чуть-чуть.

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

Не, конечно, Гедель ввел множества в КМ, хотя никакого особого смысла, кроме как «можнозделать», в этом нет. (Ну так, там дохрена чего «можнозделать», и, если б множества были не «можнозделать», ничего бы особо не случилось, никто б не плакал.)

Правда, там они являются языком, основанном на языке ZF, и ему для этого дополнительно потребовалась аксиома конструктивности («всякое множество конструктивно», а ты как думал?). А так да, все то же самое, ничего общего.

Так вот, точно так же, как, например, выражение 2a-b — это просто одно из выражений, множества в КМ — это просто язык, один из возможных, и, в этом смысле, не являются частью КМ.

Поэтому то нечто, что ты пытаешься представить как «РА», не имеет ничего общего с РА, которая «строит множества [отношения]» как результат операций над отношениями. Твоя «РА» будет оперировать с языком, а не с отношениями, как РА. И, если множества — это «ненужно» в лоровском (приемущественно) смысле, то такая, простигосподи, «РА» — натуральный костыль, во всех смыслах, потому что в КМ уже есть средство преобразования языка. Можно даже сказать, что это и есть сама КМ т.к. в основе ее — НАМ. Ну а так да, запилить свой алгорифм и обозвать его «РА» никто не мешает. Кроме того, что это НЕ РА.

Кстати, я задавал тебе вопрос, понимаешь ли ты разницу между а) и б) в твоем тезисе: «реляционная алгебра [в КМ] строит множества при помощи а) перечисления элементов б) при помощи небольшого набора операторов». Разницы нет, и а), и б) — алгорифм. Видимо, отсутствие ответа от тебя означает, что ты это понял и не «повелся». Ну чо, правильно.

Вот, читай:

Ссылка говно. Ты сам-то это читал? Или просто тыцнул по первой же ссылке, в которой гугл выделил «конструктивное определение множества» и скопировал первое (и, внезапно, единственное, бугога) более-менее подходящее предложение?

Вот эта лучше: http://dic.academic.ru/dic.nsf/enc_mathematics/2380/КОНСТРУКТИВНОЕ

А подробнее?

Сначала я подумал написать enterpice.dbf, но потом решил, что это уж через чур, и применил менее резкую формулу оскорбления.

Или ты о чем?

Или ты о чем?

Уже ни о чем. Я получил ответ, твой уже не нужен.

Правда.

Пичялька. Похоже, ты безнадежен.

Черт, видел бы это раньше — мог бы сэкономить полведра бисера. Удачи.

Люблю NoSQL, но MongoDB ужасный софт. Куча процессов и блокировок, тяжёл в настройке и управлении.

Не нужно

Чего людям Postgres какого-нибудь не хватает?

Использую это для небольшого кеша «горячих» данных мегабайт на 20 данных - постоянно какие то проблемы: то настройки слетают, то начинает в лог писать по 30МБ в секунду дампы запросов, то запускаться отказывается.

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

Транзакций нет, агрегация только только появилась, язык запросов невнятный, оверхед по памяти существенный (т.к. имена полей для каждой записи хранятся отдельно), настроек и возможностей для тюнинга мало.

Вообще, если Mongo и Postgres настроить на равных условиях (одинаковый delay на запись в журнал, одинаковый объем доступной памяти), уверен, что скорость работы, как минимум, будет сравнимой.

Вообще, если Mongo и Postgres настроить на равных условиях (одинаковый delay на запись в журнал, одинаковый объем доступной памяти), уверен, что скорость работы, как минимум, будет сравнимой.

А когда захочется одним запросом и одним disk read-ом вытащить пост блога и все дерево коментов к нему? А когда захочется горизонтально смасштабировать на запись?

А когда захочется одним запросом и одним disk read-ом вытащить

Ну не тупи же, ну! Он же написал — настроить одинаково, а это значит, что обе базы должны быть пустые. Какой бложик, ты о чем?

А когда захочется одним запросом и одним disk read-ом вытащить пост блога и все дерево коментов к нему?

и в чём проблемма? ;)

и в чём проблемма? ;)

одним запросом

Тормоза с БД

А когда захочется одним запросом и одним disk read-ом вытащить пост блога и все дерево коментов к нему?

и в чём проблемма? ;)

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

Вы просто не понимаете что это легко можно делать без join. ^_^ Архитектуру нужно верную планировать.

Вы просто не понимаете что это легко можно делать без join. ^_^ Архитектуру нужно верную планировать.

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