Я отвечу лишь на эту часть. На остальную - нет желания, ибо она непринципиальная.
Я считаю, что Вы разбираетесь в предмете, что Вы - профессионал в области файловых БД. Но мне кажется (я могу ошибаться), что как и у многих увлечённых своим продуктом предпринимателей, Вы видите возможности своей системы и значительно хуже видите возможности систем, выполняющих аналогичные функции - промышленных СУБД. И лишь в этой части было то моё высказывание. Кроме того, я создал для поисковика специализированную СУБД, хранящуюся в памяти с копией на диске, и представляю, на что у Вас могло уйти пять лет разработки. Я преклоняюсь перед такой настойчивостью в достижении целей.
А цель моих постов простая - дать людям возможность в простой форме вникнуть в проблему написания своих БД или использования сторонних не промышленных. Пусть увидят тонкости, не парятся и пользуются правильными готовыми решениями - MySQL, PostgreSQL, memcached. Да, они могут заказать или написать свою СУБД и получить соответствующий геморой. Но в итоге, по статистике, всё равно заменят всё написанное на какую-нибудь MySQL.
В этом и была суть постов. При этом, повторюсь, у меня нет никакого сомнения в Вашей компетенции в части создания софта и умения оптимизировать свой софт под высокие нагрузки.
Зато ни одна бюрократическая зараза не придерётся, что цены в каких-то там баксах или евро - никто не захочет связываться с теми, кто пишет цены в шекелях.
Кстати, что мешает разложить свои деньги согласно валютной корзине ЦБ? У меня, например, менее надёжная схема: 50% в долларах, 50% в рублях. И даже при этом я абсолютно не парюсь по поводу курса. Или есть желание сыграть с государством (российским или американским) в азартную игру на все деньги?
Надо курить мантру "Я не репрезентативен" так же часто, как студенты-маркетологи. Нужно смотреть реальную отдачу.
Это не этническая украинка. И, кстати, вопрос о её худобе временный.
Кладите.
10 красивых женщин-златовласок.
На шекели:
1. Они не привязаны к доллару.
2. Они свободно конвертируемы.
2. Нация, придумавшая банки, финансовый пузырь и кризис, не может проиграть.
А почему бы украинцам не избрать мистера Путина?
Путин - это стабильность. Путин - это отсутствие проблем с газом. Путин - это конец клоунаде. Путин - это нанотехнологии*. Путин - это навсегда. Выбирайте Путина - получите свою порцию любви.
* 1 нанотехнология = 10^(-9) от технологии.
Продавать бритву для сбривания волос с рук.
Вообще-то в поставленной задаче подавляющая часть запросов в базу будет на чтение. По остальным вопросам так же рекомендую почитать литературу про оптимизацию запросов в СУБД. Может почерпнёте что-то полезное, хотя может Вы всё это знаете и просто Вам кажется, что Ваша СУБД написана умным человеком, а остальные - дураками.
Linux настолько крут, что именем своим преодолевает физическое ограничение на время позиционирования головок при фрагментации файлов ☝
Да, он сам по себе весьма хорошо справляется с фрагментацией файлов и папок. Да, он умудряется файлы одной папки располагать рядом. Да, для чисто иерархического сайта, в котором ссылки со страницы идут в пределах одной папки и объём этих файлов невелик, число чтений диска при проходе ботами будет минимально. Но если эти 10 тыс. файлов начать активно перезаписывать, то диск начнёт активно фрагментироваться. При этом программы дефрагментации для Linux нет. Единственный на сегодняшний день способ дефрагментировать диск в Linux - удалить с него все файлы и записать отбратно.
Да, если структура сайта иерархическая, то одно считывание с диска на самых посещаемых топовых станицах будет соответствовать одному файлу - файлы лежат в разных папках, которые лежат друг от друга на диске достаточно далеко. В том же MySQL данные можно расположить так, как устроена перелинковка сайта. Например, для циклической перелинковки друг за другом в порядке следования ссылок. Например, для иерархической перелинковки по удалённости от главной страницы и близости к ссылающейся странице - чтобы более глубокие страницы, на которую ссылается менее глубокая страница, лежали рядом, а не в разных папках. Даже больше скажу: скопив статистику по времени посещения ботом страниц, эти страницы можно кластеризовать согласно этой статистике - сортировкой по времени посещения. В файловой системе это нереально.
Единственно, что всё это может быть полезно для sapёров или для дорвейщиков, так как структура сайтов у них задана и известна заранее да и боты обходят сайт по одним и тем же траекториям, начиная с корня сайта. Кроме того, их сайты больше посещают боты, а не люди. И этих ботов реально много.
У сайтов для людей структура посещаемости иная, ссылочная структура более хаотическая. Так как статистика по числу заходов не плоская, а с резким пиком вблизи главной страницы, то страницы сайта можно располагать друг рядом с другом в базе просто сортировкой по убыванию числа заходов на них. И это обеспечит очень хорошее кеширование как средствами базы, так и средствами жёсткого диска.
Да, Вы можете сделать схожий финт средствами файловой системы Linux. Например, собрав через Google Analitics статистику посещаемости и разместив самые посещаемые 10-30 страниц в одной папке. При этом придётся постоянно перетаскивать всякие новости из "папки для топовых сраниц" в папку с обычными новостями. Но нужно ли так извращаться? Может стоит потратить время на более интересные занятия, а таблицы просто поставить на автоматическую еженочную сортировку по числу посещений?
