Наша РАКЕТОМОДЕЛЬНАЯ страничка II

timochka>Эх народ, а для чего люди БАЗЫ ДАННЫХ придумали ?

Нынешние базы данных в Web - это в 90% случаев MySQL. Настроить его так, чтобы он никогда не падал и ничего не терялось - высокое искусство.

Так что самый надёжный и универсальный формат - хранить базы данных в plain/text, а SQL использовать для кеширования и запросов. Если MySQL-база падает - просто самовосстанавливается, забирая информацию из текстово базы.

Serge77>Скорее всего избыток отвердителя прореагировал с ПХА или углекислым газом и стал твёрдым. У меня лежат несколько кусочков топлив на ПХА уже 2-3 года и на вид не изменились. Один сжёг недавно, скорость горения тоже не изменилась.

Другие образцы и у меня не изменились.Я только про гибкое говорю.Еле получил ее,еще и не стойкая.

timochka>>Эх народ, а для чего люди БАЗЫ ДАННЫХ придумали ?
timochka>>Надо только движок писать для сайта

Д.Б.>Это всё само собой... напиши ?
Д.Б.>Я один всё не успею..

Не под Веб - запросто.
Под веб - увы. Просто не знаю ни Перла, ни РНР.
Я не вебные вещи делаю Такая вот специализация.
Сорри

timochka>>Эх народ, а для чего люди БАЗЫ ДАННЫХ придумали ?

=KRoN=>Нынешние базы данных в Web - это в 90% случаев MySQL. Настроить его так, чтобы он никогда не падал и ничего не терялось - высокое искусство.

Postgres SQL ? А вообщето вебные базы - увы отдельный мирок. То что юзается в корпоративных базах для веба идет плохо.

=KRoN=>Так что самый надёжный и универсальный формат - хранить базы данных в plain/text, а SQL использовать для кеширования и запросов. Если MySQL-база падает - просто самовосстанавливается, забирая информацию из текстово базы.

Наверное так. Никогда с этим не сталкивался А как вариант для на наверное покатит. А как организуется множество сообщений ? Как множество мааленьких файлов ? Или в одном файле?

timochka>Наверное так. Никогда с этим не сталкивался А как вариант для на наверное покатит. А как организуется множество сообщений ? Как множество мааленьких файлов ? Или в одном файле?

Например, этот форум сделан так. Отдельный топик - отдельный файл. Раньше все топики одного форума лежали в одном каталоге, теперь ещё растащены в подкаталоги по сотне файлов в каждом.

Совсем большие файлы плохо из-за большой нагрузки на сервер (на PHP/Perl скорость обработки подобных вещей порядка сотен килобайт в секунду), много мелких - плохо из-за большой нагрузки на файловую систему (желательно не более тысячи файлов в каталоге).

timochka>>Наверное так. Никогда с этим не сталкивался А как вариант для на наверное покатит. А как организуется множество сообщений ? Как множество мааленьких файлов ? Или в одном файле?

=KRoN=>Например, этот форум сделан так. Отдельный топик - отдельный файл. Раньше все топики одного форума лежали в одном каталоге, теперь ещё растащены в подкаталоги по сотне файлов в каждом.

=KRoN=>Совсем большие файлы плохо из-за большой нагрузки на сервер (на PHP/Perl скорость обработки подобных вещей порядка сотен килобайт в секунду), много мелких - плохо из-за большой нагрузки на файловую систему (желательно не более тысячи файлов в каталоге).

Это ясно. Собственно в этом и вопрос - какой оптимальный размер одного файла по критериям "нагрузка"/"скорость доступа". Особенно интересуют особенности индексирования и цена поддержки самовостанавливающегося индекса.

timochka>Собственно в этом и вопрос - какой оптимальный размер одного файла по критериям "нагрузка"/"скорость доступа".

Сильно зависит от того, что делать с этим файлом. Если просто прочитать - то это может быть 1..5Мб. Если как-то обрабатывать (парсинг, анализ, статистика, замены какие-то) - то объём допустимый до сотен килобайт. Естественно, речь идёт о средней, умеренной частоте обращений. Например, при каждой модификации документа. Если обработка документа производится при каждом обращении, без кеширования результата предыдущего вычисления, то объёмы хорошо бы уменьшить раз в 5..10, если обращения единичные (например, построение индекса) - то допустимо и увеличить раз в 5..10.

timochka>Особенно интересуют особенности индексирования и цена поддержки самовостанавливающегося индекса.

При аккуратной работе можно вытянуть многое. Десятки мегабайт на исходный документ. Но, вот вчера днём Авиабаза на час упала - в пик посещаемости (около 12:00) я нечаянно стёр индекс авиационного форума. Первое же обращение пошло его создавать. Создание идёт около минуты. Обращений, видимо, было дофига, ограничения на число процессов не было и... При грамотной настройке сервер бы пережил, но тут что-то было не так - всё повисло...

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

Что касается принципов построения БД то тут я за большое число мелких файлов, без использования SQL. Сам имею опыт создания подобной БД с числом мелких файлов около 40000 с веб интерфейсом. Задача упрощается тем что нет необходимости регулировать совместный доступ к файлу, поскольку файлы могут только читаться более чем одним пользователем, а, запись в файл может производить только один пользователь - автор. В такой схеме все приемущиства MySQL теряются. Немного могу писать CGI на перле, так что чем могу помогу.

MySQL лучше этих 40000 файлов если потребуется сделать запрос по ним. Найти что-то и т.п. Собственно, для этого и делают базы данных, а не для простого хранения. Хотя на многих файловых системах и простое хранение в базе оказывается быстрее, чем в файловой системе (за счёт ускорения поиска по имени).

algor17>>>Что то не совсем понял я как лучше.Мне кстати было лениво дважды описывась коментарии,сначала для своей страницы,потом для форума.В итоге остались только на форуме и заколебешься искать.
Serge77>>Идеальный вариант - это когда у каждого есть своя персональная страничка с подробным описанием его опытов, а сводная таблица на Ракетной мастерской - это краткий справочник-указатель на эти странички. А на форуме - обсуждение всего этого, после которого дополнительная информация добавляется на персональную страничку.
timochka>Эх народ, а для чего люди БАЗЫ ДАННЫХ придумали ?

Я тут подумал. И вот какая мысль ко мне пришла. Надо просто отсылать отчеты в стандартном формате. Просто заполнять форму и все. А на эти отчеты натравить уже прогу которая будет разбирать эти отчеты и генерить сводную таблицу, отдельные описания и протчее что потребуется, хоть в статик ХТМЛ хоть просто текст.
Стандартную форму отчета хорошо-бы в XML , но можно и проще вставляя в текст теги разметки.
Если эта идея народу нравиться то прогу для разбора отчетов и генерации всего чего надо я напишу.

А писание отчетов в XML - банально. Я сделаю пустую форму (рыбу) и народ который XML не знает будет просто заполнять в ней пустые поля.

Full-scale>А нельзя ли где нибудь выложить просто таблицы, можно даже в упакованом виде, пока нету базы данных.

Full-scale>Что касается принципов построения БД то тут я за большое число мелких файлов, без использования SQL. Сам имею опыт создания подобной БД с числом мелких файлов около 40000 с веб интерфейсом. Задача упрощается тем что нет необходимости регулировать совместный доступ к файлу, поскольку файлы могут только читаться более чем одним пользователем, а, запись в файл может производить только один пользователь - автор. В такой схеме все приемущиства MySQL теряются. Немного могу писать CGI на перле, так что чем могу помогу.

Проблема в том что мелкие файлы сильно жрут производительность файловой системы. Т.к. Чтение/запись данных и выделение нового места происходит блоками и эти блоки сейчас от 4кб и выще. т.е. при работе с 1 кб файлами на 1 кб полезных данных будут читаться/писаться/кешироваться еще 3 кб пустого места. т.е. нагрузка возрастет в 4 раза и 75% будет идти в холостую.
Юникс в этом смысле сильно лучше Виндов но и его тоже жалко
Это кстати один из плюсов Баз данных. Можно хранить сотни тысяч коротких записей и при этом работа с ними быстрее чем с файлами, поиск лучше, места жрут меньше, и проц загружен меньше. ))))

Крон нас сейчас расстреляет за офтоп Зверски! Из плюсомета ! ))))

timochka>Проблема в том что мелкие файлы сильно жрут производительность файловой системы.

Но не столько из-за "хвостов", сколько из-за усложнения поиска. За исключением NTFS и подобных ФС, поиск файла по имени среди 10000 файлов потребует в среднем 5000 сравнений. А это всё ещё и с диска вытащить надо... Ужас!

timochka>Т.к. Чтение/запись данных и выделение нового места происходит блоками и эти блоки сейчас от 4кб и выще.

Если не принимать во внимание FAT12/FAT16 (они сейчас только на дискеттах и Flash-карточках остались), то обычно у всех как раз по 4кБ. Иногда по 8 (у меня, например, на системном разделе )

timochka>Юникс в этом смысле сильно лучше Виндов но и его тоже жалко

Не сильно В разных ФС объём кластера 4..6кБ обычно

Впрочем, потери в хвостах всё равно пренебрежимые. На 40тыс. разнокалиберных файлов ты теряешь в среднем 40000*2/1024=~78Мб, чем в 99% случаев можно пренебречь Это не FAT16 на 2Гб винчестере, где половина диска в хвосты уходила (40000*32/1024/1024=~1.2Гб потерь )

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

И однажды уронить всё это одним движением из-за сбоя в индексе

У всего есть свои плюсы и минусы...

timochka>>Проблема в том что мелкие файлы сильно жрут производительность файловой системы.

=KRoN=>Но не столько из-за "хвостов", сколько из-за усложнения поиска. За исключением NTFS и подобных ФС, поиск файла по имени среди 10000 файлов потребует в среднем 5000 сравнений. А это всё ещё и с диска вытащить надо... Ужас!

timochka>>Юникс в этом смысле сильно лучше Виндов но и его тоже жалко
=KRoN=>Не сильно В разных ФС объём кластера 4..6кБ обычно
Я имел в виду построение ФС и грамотное кеширование. Хоть M$ и кричит что у них ОТЛИЧНЫЙ дисковый кеш, но как-то производительность сильно разная.

=KRoN=>Впрочем, потери в хвостах всё равно пренебрежимые. На 40тыс. разнокалиберных файлов ты теряешь в среднем 40000*2/1024=~78Мб, чем в 99% случаев можно пренебречь
Это на разнокалиберных файлах! При хранении одного сообщения в файле все гораздо хуже т.к. мат ожидание величины хвоста становится больше половины блока. Средний размер сообщения порядка 500 байт (условно) тогда хвост примерно 87%

Про кол-во файлов в одной директории это грабли тоже и обычно ОС с этим не борется В смысле хеш не строит и сортировать записи в каталоге не пытается ((((


timochka>>Это кстати один из плюсов Баз данных. Можно хранить сотни тысяч коротких записей и при этом работа с ними быстрее чем с файлами, поиск лучше, места жрут меньше, и проц загружен меньше. ))))
=KRoN=>И однажды уронить всё это одним движением из-за сбоя в индексе
У меня на серваке живут 3 движка (Oracle, M$ SQL, SQLBase) и по пятку баз на каждом висит. Ты не поверишь - за 3 года ни разу индексы не упали Видимо проблема в MySQL.
=KRoN=>У всего есть свои плюсы и минусы...
Эт точна! Даже у пива

timochka>Про кол-во файлов в одной директории это грабли тоже и обычно ОС с этим не борется В смысле хеш не строит и сортировать записи в каталоге не пытается ((((

Как раз в NTFS записи каталогов - реляционная БД. Среднее число сравнений ~log₂N.

timochka>У меня на серваке живут 3 движка (Oracle, M$ SQL, SQLBase) и по пятку баз на каждом висит. Ты не поверишь - за 3 года ни разу индексы не упали Видимо проблема в MySQL.

Дык, зато бесплатный... И малоресуроёмкий.

ОБНОВЛЕНИЕ РАКЕТОМОДЕЛЬНОЙ СТРАНИЧКИ

Full-scale>А нельзя ли где нибудь выложить просто таблицы, можно даже в упакованом виде, пока нету базы данных.

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

Кто-нибудь CProper пользует? И какой GUI к нему пользует GREP или CProperShell ??
А то GREP несколько минималистский Но более понятный.
А CProperShell имеет несколько малопонятных опций и выдает много больше данных.
Ну и данные расчета мягко говоря не сходятся :-(((((

timochka>>Кто-нибудь CProper пользует?

Serge77>А чем он лучше PROPEP+GUIPEP ? Пользуй их и не будет никаких расхождений.

Тем что ставиться легко. Просто распаковываются зипы в одну директорию и все. Ну и ссылок не него тоже много.
А расхождения от того что опций много.

СТОП - С расхождениями разобрался (в оболочке GREP ошибка - студент писал)!

Посчитал топливо для примера (кто-нить сравните с Proper):
Адипиновая кислота - 1 г.
НА - 75 г.
Аллюминий - 10 г.
Углерод (черный) - 15 г.
Четырех Хлористый Углерод - 1 г.

Computing case 1
Shifting equilibrium performance evaluation

Propellant composition
Code  Name                                mol    Mass (g)  Composition
13    ADIPIC ACID                         0.0068 1.0000   6C  10H  4O  
105   AMMONIUM NITRATE                    0.9370 75.0000   4H  2N  3O  
34    ALUMINUM (PURE CRYSTALINE)          0.3706 10.0000   1AL 
212   CARBON BLACK                        1.2489 15.0000   1C  
217   CARBON TETRACHLORIDE                0.0055 1.0000   1CA 4CL 
Density :  1.831 g/cm3
7 different elements
C  H  O  N  AL CA CL 
Total mass:  102.000000 g
Enthalpy  : -3364.46 kJ/kg

219 possible gazeous species
30 possible condensed species

                       CHAMBER      THROAT        EXIT
Pressure (atm)   :      68.046      38.223       1.000
Temperature (K)  :    2327.000    2138.529    1112.645
H (kJ/kg)        :   -3364.463   -3802.396   -5735.825
U (kJ/kg)        :   -4151.164   -4525.246   -6111.271
G (kJ/kg)        :  -26050.966  -24651.449  -16583.279
S (kJ/(kg)(K)    :       9.749       9.749       9.749
M (g/mol)        :      24.594      24.598      24.640
(dLnV/dLnP)t     :    -1.00000    -1.00015    -1.00049
(dLnV/dLnT)p     :     1.00000     1.00248     1.00625
Cp (kJ/(kg)(K))  :    11.26688     1.94294     1.90211
Cv (kJ/(kg)(K))  :    10.92880     1.60329     1.56061
Cp/Cv            :     1.03093     1.21184     1.21883
Gamma            :     1.03093     1.21167     1.21823
Vson (m/s)       :   900.57581   935.87042   676.29826

Ae/At            :                 1.00000     8.54374
A/dotm (m/s/atm) :                20.20731   172.35118
C* (m/s)         :              1375.02582  1375.02582
Cf               :                 0.68062     1.58381
Ivac (m/s)       :              1708.25379  2350.17807
Isp (m/s)        :               935.87042  2177.77938
Isp/g (s)        :                95.43222   222.07169

Molar fractions

ALC                 1.0269e-007 1.7176e-008 0.0000e+000
ALOCL                1.2061e-008 0.0000e+000 0.0000e+000
ALOH                 3.0459e-006 4.4607e-007 0.0000e+000
ALOHCL               7.2209e-008 1.1987e-008 0.0000e+000
ALOHCL2              1.8395e-007 7.1995e-008 0.0000e+000
AL(OH)2              6.6199e-007 9.2651e-008 0.0000e+000
AL(OH)2CL            1.9430e-006 6.4228e-007 0.0000e+000
AL(OH)3              2.4771e-005 7.5853e-006 0.0000e+000
CH3                  4.1055e-008 1.7683e-008 0.0000e+000
CH4                  8.5070e-007 7.4897e-007 1.1098e-004
CO                   2.6159e-001 2.5873e-001 2.0701e-001
CO2                  3.5930e-002 3.8801e-002 9.0417e-002
COOH                 3.0102e-007 1.0892e-007 0.0000e+000
Ca                   2.1067e-007 3.3733e-008 0.0000e+000
CaCL                 4.7241e-006 1.3817e-006 0.0000e+000
CaCL2                3.5351e-004 2.7999e-004 1.2902e-006
CaOH                 5.3071e-006 9.7337e-007 0.0000e+000
Ca(OH)2              2.7531e-004 7.8038e-005 0.0000e+000
CL                   8.2270e-006 4.0881e-006 0.0000e+000
H                    6.4972e-004 3.0915e-004 1.8144e-008
HCN                  9.5966e-006 5.5177e-006 2.4062e-007
HCO                  2.2715e-006 8.4930e-007 0.0000e+000
HCL                  4.3501e-003 4.5063e-003 2.5363e-003
HNC                  9.0351e-007 3.9504e-007 0.0000e+000
HNCO                 2.3422e-006 1.3274e-006 4.3603e-008
H2                   2.4550e-001 2.4855e-001 3.0000e-001
HCHO,formaldehy      1.8865e-006 1.0677e-006 3.4256e-008
HCOOH                1.3634e-006 7.6466e-007 2.6511e-008
H2O                  1.9169e-001 1.8902e-001 1.3862e-001
NH                   2.4720e-008 0.0000e+000 0.0000e+000
NH2                  5.3670e-007 1.7574e-007 0.0000e+000
NH3                  5.1823e-005 3.8071e-005 2.4136e-005
NO                   4.2077e-006 1.1462e-006 0.0000e+000
N2                   2.1609e-001 2.1610e-001 2.1611e-001
O                    1.5158e-007 2.6063e-008 0.0000e+000
OH                   8.4577e-005 2.9732e-005 0.0000e+000
O2                   4.9276e-008 0.0000e+000 0.0000e+000
Condensed species
AL2O3(a)             2.8262e-002 4.2740e-002 4.2744e-002
CaO(cr)              6.2908e-004 9.0773e-004 0.0000e+000
AL2O3(L)             1.4467e-002 0.0000e+000 0.0000e+000
CaCL2(L)             0.0000e+000 0.0000e+000 1.2668e-003

[ слишком длинный топик - автонарезка ]

К вопросу об интерфейсе
Смотрите сами:

timochka>Посчитал топливо для примера (кто-нить сравните с Proper):
timochka>Адипиновая кислота - 1 г.
timochka>НА - 75 г.
timochka>Аллюминий - 10 г.
timochka>Углерод (черный) - 15 г.
timochka>Четырех Хлористый Углерод - 1 г.

timochka>Computing case 1
timochka>                       CHAMBER      THROAT        EXIT
timochka>Pressure (atm)   :      68.046      38.223       1.000
timochka>Temperature (K)  :    2327.000    2138.529    1112.645

timochka>Vson (m/s)       :   900.57581   935.87042   676.29826

timochka>Ae/At            :                 1.00000     8.54374
timochka>Isp (m/s)        :               935.87042  2177.77938
timochka>Isp/g (s)        :                95.43222   222.07169

Импульс не великоват ?

timochka>>Так что предложение завести стандартную форму для отчетов народу не нравится ? Ведь и читать проще будет и сводную таблицу заполнять.

Serge77>Ты объясни, что это такое и почему будет проще? Нужно ли для этого программу писать или только форму составить?

Для этого надо просто составить форму. По смыслу та-же таблица как и было предложено. Для чего это нужно? Что-бы все посылали отчеты в одинаковом формате. А на отчеты в одинаковом формате можно натравить специально написанную программу которая составит список всех отчетов нарисует таблицу и все что угодно и ЗАПИШЕТ это богатство в готовые ХТМЛ файлы. А эти файлы - хочешь у себя смотри, хочешь на сайт выкладывай. Причем можно добавить в программу возможности поиска по заданным критериям, а результаты опять в удобном для просмотра ХТМЛ.

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

Главное=же не придется руками результаты сводить в таблицу!
Получил новый отчет, запустил программу она все это дело прошерстила и выдала готовый ХТМЛ.
В общем кто видел javadoc тот наверное уже понял.