А можете поделиться табличными данными по графикам и промежуточными по расчету интегралов?
Имхо, что-то у вас не так с расчетами — ну никак не могут красные диоды (без учета мощности, первая таблица) быть эффективнее фито. Там тонкие пики против широкого у фито на тех же частотах…
Голова болела, если подобный ионизатор-очиститель включался надолго и рядом находился. В инструкции прямо было написано не включать на ночь, рядом местом отдыха-работы и т.д.
Нет, нет, такой я нагуглил, это что-то новое. Там было осмысленное название и корпус вытянутый прямоугольник, к сожалению забыл и название, давно было…
Отличный разбор принципов работы очистителя! И эксперименты на уровне!
Однако, почему не были рассмотрены существующие бытовые очистители? Ведь что-то можно было почерпнуть и из их конструкции. Например, дома использовал бытовой очиститель-ионизатор, который производился лет 20 назад российской компанией (к сожалению не нашел фото в сети). Устройство было с проволочными коронирующими электродами, однако разряд был не лавинный, а стримерный. Второй электрод был, по-моему, в виде узких полосок. Эффективность очистителя была не особо высокой — раз в неделю вроде приходилось картридж с электродами мыть. А вот озон вырабатывал ощутимо…
это цифры для какой компрессии?
и что насчет времени при компрессии high\ultra — может тоже проблема с базами больше 2гб?
проводили ли тесты на промышленных масштабах 200-300-500Гб? я бы попробовал на 300гб базе, но поскольку база в кластере и утилита может работать только с локальным сервером, увы не получится...(
в общем, идея интересная, но для меня выгода сомнительна, поскольку в приоритете время сохранения и еще важнее восстановления — если база допустим 300гб будет восстанавливаться не полчаса, а час-два, и мне это уже критично.
пожелания — добавить больше опций, как разные виды бэкапов (dif, log), так и например очень важный параметр COPY_ONLY (пригодилось бы если текущие бэкапы делать стандартно, а иногда запускать сжатые через утилиту для архива)
попробовал протестировать на паре баз 10-20Гб (сравнивал с бэкапом и восстановлением стандартными средствами SQL с включенным сжатием):
— бэкап 7z (5-6 мин) дольше стандартного (2.5-3 мин) в 2 раза, размер меньше в 1.5-2
— бэкап zip дольше в 2 раза, размер сопоставим со стандартным
— восстановление 7z с уровнем компрессии fast (3 мин) в 2 раза медленнее стандартного (1.5 мин)
Параметр сжатия пробовал только fast\low, все что выше выдавало неприемлемую оценку по времени в 30-40 мин и я не дождался.
Восстановление из архива zip завершилось с ошибкой и открыть архив тоже не получилось.
Я правильно понял, что поддерживается также и восстановление?
Проводили ли вы сравнение с процедурой сохранения\восстановления стандартными средствами (+сжатие)? Конечно же интересует время выполнения.
Имхо, что-то у вас не так с расчетами — ну никак не могут красные диоды (без учета мощности, первая таблица) быть эффективнее фито. Там тонкие пики против широкого у фито на тех же частотах…
Однако, почему не были рассмотрены существующие бытовые очистители? Ведь что-то можно было почерпнуть и из их конструкции. Например, дома использовал бытовой очиститель-ионизатор, который производился лет 20 назад российской компанией (к сожалению не нашел фото в сети). Устройство было с проволочными коронирующими электродами, однако разряд был не лавинный, а стримерный. Второй электрод был, по-моему, в виде узких полосок. Эффективность очистителя была не особо высокой — раз в неделю вроде приходилось картридж с электродами мыть. А вот озон вырабатывал ощутимо…
и что насчет времени при компрессии high\ultra — может тоже проблема с базами больше 2гб?
проводили ли тесты на промышленных масштабах 200-300-500Гб? я бы попробовал на 300гб базе, но поскольку база в кластере и утилита может работать только с локальным сервером, увы не получится...(
в общем, идея интересная, но для меня выгода сомнительна, поскольку в приоритете время сохранения и еще важнее восстановления — если база допустим 300гб будет восстанавливаться не полчаса, а час-два, и мне это уже критично.
пожелания — добавить больше опций, как разные виды бэкапов (dif, log), так и например очень важный параметр COPY_ONLY (пригодилось бы если текущие бэкапы делать стандартно, а иногда запускать сжатые через утилиту для архива)
попробовал протестировать на паре баз 10-20Гб (сравнивал с бэкапом и восстановлением стандартными средствами SQL с включенным сжатием):
— бэкап 7z (5-6 мин) дольше стандартного (2.5-3 мин) в 2 раза, размер меньше в 1.5-2
— бэкап zip дольше в 2 раза, размер сопоставим со стандартным
— восстановление 7z с уровнем компрессии fast (3 мин) в 2 раза медленнее стандартного (1.5 мин)
Параметр сжатия пробовал только fast\low, все что выше выдавало неприемлемую оценку по времени в 30-40 мин и я не дождался.
Восстановление из архива zip завершилось с ошибкой и открыть архив тоже не получилось.
Проводили ли вы сравнение с процедурой сохранения\восстановления стандартными средствами (+сжатие)? Конечно же интересует время выполнения.