Вопросы по Cronos, другим базам и программам

[spec141]

В основном у меня была надежда, что в 6.4 решили проблему с импортом больших csv файлов. Но похоже ситуация по сравнению с 5 не изменилась

[broyury]

В основном у меня была надежда, что в 6.4 решили проблему с импортом больших csv файлов. Но похоже ситуация по сравнению с 5 не изменилась

уже года 2 как 7.0, а с 01.09.22 7.1 версия
там много изменений [External Link Removed for Guests]
правда есть 1 существенный минус, созданные БД в 7.0 не открыть в 5.0, и старые БД у меня не получилось открыть, так как он ругается на серийный номер.

[konkar]

В основном у меня была надежда, что в 6.4 решили проблему с импортом больших csv файлов. Но похоже ситуация по сравнению с 5 не изменилась

уже года 2 как 7.0, а с 01.09.22 7.1 версия
там много изменений [External Link Removed for Guests]
правда есть 1 существенный минус, созданные БД в 7.0 не открыть в 5.0, и старые БД у меня не получилось открыть, так как он ругается на серийный номер.

До сих пор все официальные версии были лояльны к СН=1. В 3 версии номер можно исправить на любой (1061 защита банка), в "вышестоящих" придется через копирование (без защиты серийным номером)

[PiMar]

уже года 2 как 7.0, а с 01.09.22 7.1 версия
там много изменений [External Link Removed for Guests]
правда есть 1 существенный минус, созданные БД в 7.0 не открыть в 5.0, и старые БД у меня не получилось открыть, так как он ругается на серийный номер.

7.0 c 26.09.2019 - уже три года.
с 01.09.2021 - 7.1 версия. На оф. сайте ошибка с датой.

В основном у меня была надежда, что в 6.4 решили проблему с импортом больших csv файлов. Но похоже ситуация по сравнению с 5 не изменилась

Проблема осталась и в версии 7.1. Файлы более 2 Гб начинают "косячить" при импорте. Простейший способ обхода - разбиение простеньким скриптом большого файла на несколько.

[ikumf]

5 Версия плохо обрабатывает файлы больше 4 гб. Файл делится EmEditor на куски меньше 4 гб. Также кронос не может использовать процессор на 100%. Поэтому для оптимизации логично большой файл резать как минимум на 3 куска, открывать три кроноса и параллельно конвертировать. У меня на i5-9400F три конвертирующих кроноса загружают процессор на 75-80%. На оставшейся мощности можно параллельно работать. Дальше 3 базы сливаются в одну. Так что в этом ограничении есть и плюсы.

[PiMar]

... Также кронос не может использовать процессор на 100%. Поэтому для оптимизации логично большой файл резать как минимум на 3 куска, открывать три кроноса и параллельно конвертировать. У меня на i5-9400F три конвертирующих кроноса загружают процессор на 75-80%. На оставшейся мощности можно параллельно работать. Дальше 3 базы сливаются в одну...

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

[corex]

5 Версия плохо обрабатывает файлы больше 4 гб. Файл делится EmEditor на куски меньше 4 гб. Также кронос не может использовать процессор на 100%. Поэтому для оптимизации логично большой файл

Ни одна версия Кронос не импортирует корректно данные более 4 Гб одним файлом, строки будут разорваны, данные зайдут частично с произвольными разрывами именно всё что свыше 4 Гб.
Это может быть не 4096 Мб файл, а чуть меньше, 4030-4040 Мб, если импортировать, как раз этот мизер свыше 4030 Мб и будет разорван на части. Попробуйте 4100 Мб сделать и увидите.
Возможно это связано с размером самого банка в 4 Гб, в тексте это как раз будет чуть меньше 4 Гб веса исходника, точно не известно, но более 4000 Мб не делают.
Если у вас ограниченный объем оперативной памяти, она старая (если что уже DDR5 в ходу), определяется это ее загрузкой, если свыше 50%, ее может не хватать, задействуется виртуальная память, то же и загрузки процессора касается, если он у вас под 100% грузится, то вычислительных возможностей вам не хватает, будет легче на чуть меньший объем делить файлы.
У вас процессор за 150 баксов, coffee lake 2019 года, с DDR-4 2666 Mhz. Урезанный чипсет 1151 который частоту выше не понимает. Это как раз для работы Кроноса важней ваших ядер. Хотя i5 не лучший выбор под Кронос.
На i7 восьмого или девятого поколения я тормозов таких не видел, что бы проц грузился на 100%. Может у вас оперативной памяти мало? Маловато 8х2 Гб. Но мой вам совет, меняйте систему, со временем этот переходной уровень обесценится, потеряете больше, это тупиковая версия под камень с лимитом под частоты памяти даже. От этого лучше избавляться скорее, обесценится это быстрее чем 2-5 поколения, они так быстро не появлялись. Возьмите просто что-то новое минимум 16 Гб оперативы DDR-5 и будет быстрее.
Диски так же важны. Заметна разница работы на m.2 NVMe, даже на фоне обычных SSD небо и земля, на объемных файлах очень заметна разница в скорости чтения и преобразований.
Скорость и загруженность зависит от вашей системы. У меня 4 Гб считываются и импортируются за несколько минут (не скажу точно, редко пользуюсь), но у меня и станция почти серверной мощности (работа требует), но не могу сказать что Кронос на ней летает, совсем напротив на фоне заметной скорости в работе всего в сравнении с обычными ПК, ноутбуками, это очень заметно, что это софт времен Windows XP. Я им редко пользуюсь, он безнадежно устарел.
Как хранилище данных, глобальный поиск, выбор решения понятен и оправдан. Но по скорости работы в нем, для хранения разрозненных массивов, Кронос не практичен. Времени на работу с ним требуется уже заметно много. Он в ДЕСЯТКИ раз медленней всего, что мне известно из работы СУБД, именно внутри операции с данными. Ну то что принято считать что в новых версиях работает быстрее, не в десятки а в два, три и до четырех раз медленней. По этой причине это не лучший выбор для преобразования с нуля и хранения массивов. Для хранения своих данных, скоринга и всяких баз вполне годно.
Как выбор решения с нуля, это не практично. Потратьте время на обучение, возможно курсы какие-то. Изучите и освойте другую СУБД, проживете дольше и сделаете больше.
Если конечно вам всё это бесплатно и даром не готовят, тогда выбирать СУБД не приходится.

[Leo666]

5 Версия плохо обрабатывает файлы больше 4 гб. Файл делится EmEditor на куски меньше 4 гб. Также кронос не может использовать процессор на 100%. Поэтому для оптимизации логично большой файл

Ни одна версия Кронос не импортирует корректно данные более 4 Гб одним файлом, строки будут разорваны, данные зайдут частично с произвольными разрывами именно всё что свыше 4 Гб.
Это может быть не 4096 Мб файл, а чуть меньше, 4030-4040 Мб, если импортировать, как раз этот мизер свыше 4030 Мб и будет разорван на части. Попробуйте 4100 Мб сделать и увидите.
Возможно это связано с размером самого банка в 4 Гб, в тексте это как раз будет чуть меньше 4 Гб веса исходника, точно не известно, но более 4000 Мб не делают.
Если у вас ограниченный объем оперативной памяти, она старая (если что уже DDR5 в ходу), определяется это ее загрузкой, если свыше 50%, ее может не хватать, задействуется виртуальная память, то же и загрузки процессора касается, если он у вас под 100% грузится, то вычислительных возможностей вам не хватает, будет легче на чуть меньший объем делить файлы.
У вас процессор за 150 баксов, coffee lake 2019 года, с DDR-4 2666 Mhz. Урезанный чипсет 1151 который частоту выше не понимает. Это как раз для работы Кроноса важней ваших ядер. Хотя i5 не лучший выбор под Кронос.
На i7 восьмого или девятого поколения я тормозов таких не видел, что бы проц грузился на 100%. Может у вас оперативной памяти мало? Маловато 8х2 Гб. Но мой вам совет, меняйте систему, со временем этот переходной уровень обесценится, потеряете больше, это тупиковая версия под камень с лимитом под частоты памяти даже. От этого лучше избавляться скорее, обесценится это быстрее чем 2-5 поколения, они так быстро не появлялись. Возьмите просто что-то новое минимум 16 Гб оперативы DDR-5 и будет быстрее.
Диски так же важны. Заметна разница работы на m.2 NVMe, даже на фоне обычных SSD небо и земля, на объемных файлах очень заметна разница в скорости чтения и преобразований.
Скорость и загруженность зависит от вашей системы. У меня 4 Гб считываются и импортируются за несколько минут (не скажу точно, редко пользуюсь), но у меня и станция почти серверной мощности (работа требует), но не могу сказать что Кронос на ней летает, совсем напротив на фоне заметной скорости в работе всего в сравнении с обычными ПК, ноутбуками, это очень заметно, что это софт времен Windows XP. Я им редко пользуюсь, он безнадежно устарел.
Как хранилище данных, глобальный поиск, выбор решения понятен и оправдан. Но по скорости работы в нем, для хранения разрозненных массивов, Кронос не практичен. Времени на работу с ним требуется уже заметно много. Он в ДЕСЯТКИ раз медленней всего, что мне известно из работы СУБД, именно внутри операции с данными. Ну то что принято считать что в новых версиях работает быстрее, не в десятки а в два, три и до четырех раз медленней. По этой причине это не лучший выбор для преобразования с нуля и хранения массивов. Для хранения своих данных, скоринга и всяких баз вполне годно.
Как выбор решения с нуля, это не практично. Потратьте время на обучение, возможно курсы какие-то. Изучите и освойте другую СУБД, проживете дольше и сделаете больше.
Если конечно вам всё это бесплатно и даром не готовят, тогда выбирать СУБД не приходится.

Начиная с версии 7.2, все указанные проблемы по импорту больших файлов, устранены.
импорт 90 млн строк занял 8 мин на i5

[PiMar]

...Если у вас ограниченный объем оперативной памяти, она старая (если что уже DDR5 в ходу), определяется это ее загрузкой, если свыше 50%, ее может не хватать, задействуется виртуальная память, то же и загрузки процессора касается, если он у вас под 100% грузится, то вычислительных возможностей вам не хватает, будет легче на чуть меньший объем делить файлы.
У вас процессор за 150 баксов, coffee lake 2019 года, с DDR-4 2666 Mhz. Урезанный чипсет 1151 который частоту выше не понимает. Это как раз для работы Кроноса важней ваших ядер. Хотя i5 не лучший выбор под Кронос.
На i7 восьмого или девятого поколения я тормозов таких не видел, что бы проц грузился на 100%. Может у вас оперативной памяти мало? Маловато 8х2 Гб. Но мой вам совет, меняйте систему, со временем этот переходной уровень обесценится, потеряете больше, это тупиковая версия под камень с лимитом под частоты памяти даже. От этого лучше избавляться скорее, обесценится это быстрее чем 2-5 поколения, они так быстро не появлялись. Возьмите просто что-то новое минимум 16 Гб оперативы DDR-5 и будет быстрее.
Диски так же важны. Заметна разница работы на m.2 NVMe, даже на фоне обычных SSD небо и земля, на объемных файлах очень заметна разница в скорости чтения и преобразований...

А зачем для СУБД, такого рода как мы используем, большие вычислительные возможности? Нету там никаких нагрузок на вычисления. Основная задача при поиске перебор всех записей с диска и вычленение нужных. Это при отсутствии индексов. При их присутствии получение из индексного массива системных номеров нужных записей и их выдача.
Основная нагрузка на диск и скорость работы с данными. В этом основное ограничение. Вычислительные возможности и скорость даже старых процессоров значительно опережают скорость работы дисков. Самые тормознутые операции это дисковые и вывод на экран.

[corex]

А зачем для СУБД, такого рода как мы используем, большие вычислительные возможности?

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

Нету там никаких нагрузок на вычисления. Основная задача при поиске перебор всех записей с диска и вычленение нужных. Это при отсутствии индексов. При их присутствии получение из индексного массива системных номеров нужных записей и их выдача.
Основная нагрузка на диск и скорость работы с данными. В этом основное ограничение. Вычислительные возможности и скорость даже старых процессоров значительно опережают скорость работы дисков. Самые тормознутые операции это дисковые и вывод на экран.

Не несите вздор, по такой логике все линейки поколений процессоров работают одинаково по времени выполнения задачи, начиная с системных требований.
Речь не шла о поиске и работе с готовой базой, речь шла о постоянной занятости в этой области.
Мне не интересно ваше мнение об этом, как и мнение иных специалистов в области работы с данными, вся явная суть познаний которых сводится к очевидностям вроде база без индексов медленно работает. Уверен, что ваше мнение об этом будет очень интересно другим.