Для того, чтобы число файлов PostgreSQL выросло до миллиона, достаточно несколько десятков тысяч таблиц, что я легко наблюдал на производственных предприятих. Любая таблица без индексов - уже минимум три файла (данные, карта свободного места и карта видимости). Каждый индекс - два файла (индекс и карта свободного места). То есть, одна таблица с восемью индексами - два десятка файлов. И это не считая вороха временных таблиц на каждого пользователя.
"Под миллион", как я писал выше - это фактическая картина для 1С на предприятии по производству ювелирных часов.
И при чем тут количество файлов для серверного субпроцесса? Эти субпроцессы форкаются в PostgreSQL по десятку-другому на один запрос.
Во-первых, раз речь об 1С, количество файлов может оказаться под миллион, так как каждый раздел и индекс - отдельный файл. По крайней мере на первой попавшейся мне сейчас под руку продуктивной БД PostgreSQL 500 таблиц хранятся в 7 тысячах файлах.
Во-вторых, это MS SQL держит все файлы открытыми, так как их у него на пальцах можно пересчитать. PostgreSQL так не делает и открывает/закрывает файлы по мере надобности в них. И в том то и проблема, что на современных FS в Linux операции открытия/закрытия файлов при работе PostgreSQL занимают меньше миллисекунды (не забываем об указании noatime,nodiratime при монтировании), тогда как на NTFS - несколько миллисекунд. Оба времени - с учетом кеширования.
Подозрительно большая разница. Складывается ощущение, что на MS SQL все запросы живут с MAXDOP 0, а на PostgreSQL параллелизация запросов сильно ограничена настройками.
Хотелось бы отметить, что Windows для PostgreSQL инородная среда, под которой оценивать его производительность уж точно не стоит. По двум причинам:
Во-первых, PostgreSQL каждый объект БД (раздел таблицы, индекс и т.п.) хранит в отдельном файле. А производительность даже древней ext3 при больших количествах файлов в одной директории, заметно выше, чем NTFS. Что уж говорить о современных файловых системах? В MS SQL эта проблема решается просто отказом от работы с файловой системой в процессе работы сервера и размещением всех объектов БД в одном или нескольких постоянно открытых файлах.
Во-вторых, PostgreSQL активно пользуется fork(), реализация которого под Windows далека от оптимальной. В первую очередь из-за отсутствия Copy-on-Write. Иными словами, если под Linux fork() выполняется почти мгновенно, откладывая копирование страниц памяти на потом, и только при их модификации, то под Windows такой возможности нет и при fork() выполняется принудительное копирование всей памяти процесса.
Ну, на базе в несколько гигабайт и с 500000+ записями она была быстрой) Главное индексы ставить.
Вы прикалываетесь или издеваетесь? БД в несколько гигабайт почти всегда вся в оперативку влетит. Я, обычно, занимаюсь БД размером от нескольких терабайт и миллиардами записей. Вот там уже можно что-то говорить о производительности СУБД.
И на таких объемах MongoDB действительно сильно уступает по производительности сложных аналитических запросов таким СУБД, как ClickHouse или PostgreSQL. Но замечательно подходит, как буферная БД для сбора информации из внешних сервисов, в которых без предупреждения могут меняться как типы полей, так и появляться новые поля или даже целые подчинённые структуры.
Это как раз понятно. Сейчас воздушно-алюминиевые батареи, скорее всего, обойдутся дороже в эксплуатации, чем литий-ионные аккумуляторы. Но если первые имеют хорошие перспективы прорывов как в снижении стоимости, так и в улучшении иных параметров, то для последних прорывы уже маловероятны.
Но это частности. Суть в том, что одноразовые и условно-одноразовые (меняем только катод или анод) источники питания имеют свои преимущества. Если можно будет менять батареи только при плановом техобслуживании, вообще не заботясь о зарядке или заправке в межсервисные интервалы - это вполне может быть востребовано потребителем даже при большей стоимости. На той же фуре-автопилоте можно поменять батареи при погрузке-разгрузке, но зато потом проехать несколько тысяч километров вообще без остановок.
И возникает резонный вопрос. Что лучше, каждые 200 километров становиться на зарядку, или каждые 4000 километров менять батарейки? Как вариант - алюминий в воздушно-алюминиевых источниках питания.
Не надоело придираться к словам? ULN2003 представляет собой просто сборку в одном корпусе семи дарлингтонов с защитными диодами.
Шаговый двигатель с ULN2003 = шаговый двигатель с уже установленной прямо на его корпусе платой с ULN2003 = шаговый двигатель с уже установленными защитными диодами.
Супрессор - это и есть защитный диод. А вопросы надо задавать так, чтобы их можно было понять однозначно.
Вы написали "Биполярные шаговые двигатели с установленными защитными диодами?". Поэтому я и дал ссылку на статью, где описаны защитные диоды для биполярных двигателей (симметричные). Совершенно не подозревая, что слово "биполярные" в Вашем вопросе было совершенно излишним.
Что касается "с установленными защитными диодами", то ищите шаговый двигатель с драйвером. На драйвере защитные диоды уже будут.
Защитный диод необходим при любых раскладах, так как обмотки шагового двигателя имеют индуктивность, ток в которой прекратиться мгновенно не может. А если ток есть, а сопротивление цепи велико, то будет нарастать напряжение. Причем обратное и, теоретически, бесконечно большое. Выходы МК пробиваются в легкую.
Скорее всего, Вам просто везло, что попадались шаговые двигатели с уже установленными защитными диодами.
Для того, чтобы число файлов PostgreSQL выросло до миллиона, достаточно несколько десятков тысяч таблиц, что я легко наблюдал на производственных предприятих. Любая таблица без индексов - уже минимум три файла (данные, карта свободного места и карта видимости). Каждый индекс - два файла (индекс и карта свободного места). То есть, одна таблица с восемью индексами - два десятка файлов. И это не считая вороха временных таблиц на каждого пользователя.
"Под миллион", как я писал выше - это фактическая картина для 1С на предприятии по производству ювелирных часов.
И при чем тут количество файлов для серверного субпроцесса? Эти субпроцессы форкаются в PostgreSQL по десятку-другому на один запрос.
Во-первых, раз речь об 1С, количество файлов может оказаться под миллион, так как каждый раздел и индекс - отдельный файл. По крайней мере на первой попавшейся мне сейчас под руку продуктивной БД PostgreSQL 500 таблиц хранятся в 7 тысячах файлах.
Во-вторых, это MS SQL держит все файлы открытыми, так как их у него на пальцах можно пересчитать. PostgreSQL так не делает и открывает/закрывает файлы по мере надобности в них. И в том то и проблема, что на современных FS в Linux операции открытия/закрытия файлов при работе PostgreSQL занимают меньше миллисекунды (не забываем об указании noatime,nodiratime при монтировании), тогда как на NTFS - несколько миллисекунд. Оба времени - с учетом кеширования.
Подозрительно большая разница. Складывается ощущение, что на MS SQL все запросы живут с MAXDOP 0, а на PostgreSQL параллелизация запросов сильно ограничена настройками.
Хотелось бы отметить, что Windows для PostgreSQL инородная среда, под которой оценивать его производительность уж точно не стоит. По двум причинам:
Во-первых, PostgreSQL каждый объект БД (раздел таблицы, индекс и т.п.) хранит в отдельном файле. А производительность даже древней ext3 при больших количествах файлов в одной директории, заметно выше, чем NTFS. Что уж говорить о современных файловых системах? В MS SQL эта проблема решается просто отказом от работы с файловой системой в процессе работы сервера и размещением всех объектов БД в одном или нескольких постоянно открытых файлах.
Во-вторых, PostgreSQL активно пользуется fork(), реализация которого под Windows далека от оптимальной. В первую очередь из-за отсутствия Copy-on-Write. Иными словами, если под Linux fork() выполняется почти мгновенно, откладывая копирование страниц памяти на потом, и только при их модификации, то под Windows такой возможности нет и при fork() выполняется принудительное копирование всей памяти процесса.
Вы прикалываетесь или издеваетесь? БД в несколько гигабайт почти всегда вся в оперативку влетит. Я, обычно, занимаюсь БД размером от нескольких терабайт и миллиардами записей. Вот там уже можно что-то говорить о производительности СУБД.
И на таких объемах MongoDB действительно сильно уступает по производительности сложных аналитических запросов таким СУБД, как ClickHouse или PostgreSQL. Но замечательно подходит, как буферная БД для сбора информации из внешних сервисов, в которых без предупреждения могут меняться как типы полей, так и появляться новые поля или даже целые подчинённые структуры.
Это как раз понятно. Сейчас воздушно-алюминиевые батареи, скорее всего, обойдутся дороже в эксплуатации, чем литий-ионные аккумуляторы. Но если первые имеют хорошие перспективы прорывов как в снижении стоимости, так и в улучшении иных параметров, то для последних прорывы уже маловероятны.
Но это частности. Суть в том, что одноразовые и условно-одноразовые (меняем только катод или анод) источники питания имеют свои преимущества. Если можно будет менять батареи только при плановом техобслуживании, вообще не заботясь о зарядке или заправке в межсервисные интервалы - это вполне может быть востребовано потребителем даже при большей стоимости. На той же фуре-автопилоте можно поменять батареи при погрузке-разгрузке, но зато потом проехать несколько тысяч километров вообще без остановок.
И возникает резонный вопрос. Что лучше, каждые 200 километров становиться на зарядку, или каждые 4000 километров менять батарейки? Как вариант - алюминий в воздушно-алюминиевых источниках питания.
Все зависит от задач. В ряде случаев CoW дает существенный выигрыш оперативной памяти и производительности.
Во-первых, к двигателю плату не паяют. Обычно, она крепится или на защелках, или прикручивается.
Во-вторых, если двигатели с UNL2003 мне попадались часто, то реже попадались двигатели и с A4988, который именно для биполярных шаговых двигателей.
В-третьих, когда только задают странные вопросы не утверждая вообще ничего, это выглядит высокомерным и некультурным.
Не надоело придираться к словам? ULN2003 представляет собой просто сборку в одном корпусе семи дарлингтонов с защитными диодами.
Шаговый двигатель с ULN2003 = шаговый двигатель с уже установленной прямо на его корпусе платой с ULN2003 = шаговый двигатель с уже установленными защитными диодами.
Так устроит наконец-то?
Мне встречались шаговые двигатели, например, с ULN2003, который уже содержит защитные диоды.
Но так как эти средства открытые, никто не запрещает самостоятельно добавлять туда что пожелаете.
А если еще и поделитесь тем, что добавили, заработаете плюс себе в карму )
Это именно эмулятор, а вовсе не внутрисхемный отладчик. Со всеми вытекающими
Супрессор - это и есть защитный диод. А вопросы надо задавать так, чтобы их можно было понять однозначно.
Вы написали "Биполярные шаговые двигатели с установленными защитными диодами?". Поэтому я и дал ссылку на статью, где описаны защитные диоды для биполярных двигателей (симметричные). Совершенно не подозревая, что слово "биполярные" в Вашем вопросе было совершенно излишним.
Что касается "с установленными защитными диодами", то ищите шаговый двигатель с драйвером. На драйвере защитные диоды уже будут.
Никто не запрещает использовать самодельный открытый программатор, себестоимостью на порядок меньшей. Ссылку я привел выше.
Почему бы нет? Почитайте https://go-radio.ru/supressor.html
Защитный диод необходим при любых раскладах, так как обмотки шагового двигателя имеют индуктивность, ток в которой прекратиться мгновенно не может. А если ток есть, а сопротивление цепи велико, то будет нарастать напряжение. Причем обратное и, теоретически, бесконечно большое. Выходы МК пробиваются в легкую.
Скорее всего, Вам просто везло, что попадались шаговые двигатели с уже установленными защитными диодами.
Есть. Смотрите мой комментарий ниже. Там же все ссылки.
В дополнение к статье, хотелось бы указать, что для МК Padauk есть так же открытые средства разработки:
USB программатор https://github.com/free-pdk/easy-pdk-programmer-hardware на базе STM32F072C8T6 и программа к нему https://github.com/free-pdk/easy-pdk-programmer-software
Дизассемблер с эмулятором https://github.com/free-pdk/fppa-pdk-tools
Ну и, собственно говоря, C компилятор SDCC http://sdcc.sourceforge.net/ на данный момент поддерживающий pdk14, pdk15, и в процессе еще pdk13.
Так что имеем полностью свободный tool-chain с нормальным C и работающий под любой системой.
Получится. SDCC уже многие модели Padauk поддерживает