diakas
Jr. Member
Offline
Activity: 245
Merit: 1
|
|
December 03, 2018, 08:27:33 PM |
|
Предлагаю добавить ограничение по выводу на монеты не в процентном, а в количественном виде, например - биток не более 0.1 за один вывод и сделать скрипт скидывающий с горячего кошелька биржи суммы превышающие это значение на холодный - тогда убытки от взлома будут минимизированы.
Кстати какие идеи где править ограничения на вывод, кто подскажет?
|
|
|
|
|
|
|
|
|
It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
Nikita K
Newbie
Offline
Activity: 157
Merit: 0
|
|
December 26, 2018, 06:51:31 PM |
|
Скорость работы невыносимая
|
|
|
|
kzv (OP)
Legendary
Offline
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
|
|
December 27, 2018, 03:51:25 AM |
|
Скорость работы невыносимая
Вчера были технические работы. Перешел на архитектуру с отдельным сервером базы данных. Сейчас скорость даже получше стала чем когда все в одном процессе работало. Ну и теперь открылись возможности для масштабирования.
|
|
|
|
dzyk
Legendary
Offline
Activity: 1792
Merit: 1028
dzyk.ru
|
|
December 27, 2018, 05:12:52 AM |
|
Скорость работы невыносимая
Вчера были технические работы. Перешел на архитектуру с отдельным сервером базы данных. Сейчас скорость даже получше стала чем когда все в одном процессе работало. Ну и теперь открылись возможности для масштабирования. какая БД?
|
|
|
|
kzv (OP)
Legendary
Offline
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
|
|
December 27, 2018, 05:43:59 AM |
|
Скорость работы невыносимая
Вчера были технические работы. Перешел на архитектуру с отдельным сервером базы данных. Сейчас скорость даже получше стала чем когда все в одном процессе работало. Ну и теперь открылись возможности для масштабирования. какая БД? База как была SQlite так и осталась. Но теперь она крутится в отдельном от биржи процессе и теперь к ней можно из разных процессов обращаться.
|
|
|
|
fxpc
Sr. Member
Offline
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
|
|
December 27, 2018, 09:50:10 PM |
|
Скорость работы невыносимая
Вчера были технические работы. Перешел на архитектуру с отдельным сервером базы данных. Сейчас скорость даже получше стала чем когда все в одном процессе работало. Ну и теперь открылись возможности для масштабирования. какая БД? База как была SQlite так и осталась. Но теперь она крутится в отдельном от биржи процессе и теперь к ней можно из разных процессов обращаться. Чем не устраивает какой-нибудь PostgreSQL?
|
|
|
|
kzv (OP)
Legendary
Offline
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
|
|
December 28, 2018, 03:30:47 AM |
|
Чем не устраивает какой-нибудь PostgreSQL?
В том то и дело, что "какой-нибудь"... Я для себя сформулировал сначала: что мне нужно от базы данных: 1. Чтобы умела SQL запросы 2. Хммм... Все собственно. Если не собираешься писать логику работы на голом SQL (таких умельцев хватает), а используешь более или менее нормальный высокоуровневый язык, то для бухгалтерской книги подойдет вообще любая база данных. Выбор SQLite для меня был естественным: с этой базой у меня есть выбор - использовать ее как встроенную в процесс или вынести в отдельный сервер. С большинством остальных баз такого выбора нет - отдельный процесс-сервер без вариантов. Чем лучше встроенная база? Тем, что ее скорость всегда будет в сотни раз выше любой базы на отдельном сервере. Ибо общение между процессами всегда проходит сильно медленней, чем общение процесса внутри себя.
|
|
|
|
fxpc
Sr. Member
Offline
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
|
|
December 28, 2018, 10:36:57 AM |
|
Чем не устраивает какой-нибудь PostgreSQL?
В том то и дело, что "какой-нибудь"... Я для себя сформулировал сначала: что мне нужно от базы данных: 1. Чтобы умела SQL запросы 2. Хммм... Все собственно. Если не собираешься писать логику работы на голом SQL (таких умельцев хватает), а используешь более или менее нормальный высокоуровневый язык, то для бухгалтерской книги подойдет вообще любая база данных. Выбор SQLite для меня был естественным: с этой базой у меня есть выбор - использовать ее как встроенную в процесс или вынести в отдельный сервер. С большинством остальных баз такого выбора нет - отдельный процесс-сервер без вариантов. Чем лучше встроенная база? Тем, что ее скорость всегда будет в сотни раз выше любой базы на отдельном сервере. Ибо общение между процессами всегда проходит сильно медленней, чем общение процесса внутри себя. Либо я чего-то не понял, либо ты себе противоречишь, когда пишешь что перевёл базу данных в отдельный процесс и скорость стала получше. Если у биржи мало клиентов, то конечно с нагрузкой справится любая БД. Не знаю специфику запросов твоей биржи, но SQLite точно сливает enterprise решениям при высокой нагрузке и даже при низкой, когда ей сопутствует большое количество writes.
|
|
|
|
dzyk
Legendary
Offline
Activity: 1792
Merit: 1028
dzyk.ru
|
|
December 28, 2018, 10:56:06 AM |
|
Чем не устраивает какой-нибудь PostgreSQL?
В том то и дело, что "какой-нибудь"... Я для себя сформулировал сначала: что мне нужно от базы данных: 1. Чтобы умела SQL запросы 2. Хммм... Все собственно. Если не собираешься писать логику работы на голом SQL (таких умельцев хватает), а используешь более или менее нормальный высокоуровневый язык, то для бухгалтерской книги подойдет вообще любая база данных. Выбор SQLite для меня был естественным: с этой базой у меня есть выбор - использовать ее как встроенную в процесс или вынести в отдельный сервер. С большинством остальных баз такого выбора нет - отдельный процесс-сервер без вариантов. Чем лучше встроенная база? Тем, что ее скорость всегда будет в сотни раз выше любой базы на отдельном сервере. Ибо общение между процессами всегда проходит сильно медленней, чем общение процесса внутри себя. да. лучше всего проводить операции обмена сразу в регистрах процессора) или хотя бы в озу)))) Либо я чего-то не понял, либо ты себе противоречишь, когда пишешь что перевёл базу данных в отдельный процесс и скорость стала получше. Если у биржи мало клиентов, то конечно с нагрузкой справится любая БД. Не знаю специфику запросов твоей биржи, но SQLite точно сливает enterprise решениям при высокой нагрузке и даже при низкой, когда ей сопутствует большое количество writes. да. лучше всего проводить операции обмена сразу в регистрах процессора) или хотя бы в озу)))) но для надежности лучше писать каждый обмен в ячейку SSD TLC/MLC NAND))) У автора не стоит пока цели оптимизации скорости работы. ПОка все упирается в дизайн и безопасность фреймворков
|
|
|
|
fxpc
Sr. Member
Offline
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
|
|
December 28, 2018, 11:45:29 AM |
|
Чем не устраивает какой-нибудь PostgreSQL?
В том то и дело, что "какой-нибудь"... Я для себя сформулировал сначала: что мне нужно от базы данных: 1. Чтобы умела SQL запросы 2. Хммм... Все собственно. Если не собираешься писать логику работы на голом SQL (таких умельцев хватает), а используешь более или менее нормальный высокоуровневый язык, то для бухгалтерской книги подойдет вообще любая база данных. Выбор SQLite для меня был естественным: с этой базой у меня есть выбор - использовать ее как встроенную в процесс или вынести в отдельный сервер. С большинством остальных баз такого выбора нет - отдельный процесс-сервер без вариантов. Чем лучше встроенная база? Тем, что ее скорость всегда будет в сотни раз выше любой базы на отдельном сервере. Ибо общение между процессами всегда проходит сильно медленней, чем общение процесса внутри себя. Либо я чего-то не понял, либо ты себе противоречишь, когда пишешь что перевёл базу данных в отдельный процесс и скорость стала получше. Если у биржи мало клиентов, то конечно с нагрузкой справится любая БД. Не знаю специфику запросов твоей биржи, но SQLite точно сливает enterprise решениям при высокой нагрузке и даже при низкой, когда ей сопутствует большое количество writes. для надежности лучше писать каждый обмен в ячейку SSD TLC/MLC NAND))) У автора не стоит пока цели оптимизации скорости работы. ПОка все упирается в дизайн и безопасность фреймворков Не лучше, SSD не отличаются надёжностью, но я вроде про неё не говорил. Если бы не стояло такой цели, то он бы её не оптимизировал. Enterprise избыточен для операций чтения, для чего-то более сложного он незаменим. Выбор движка менее чувствительного к характеру нагрузки это не совсем оптимизация, а скорее сокращение издержек на поддержку и масштабирование.
|
|
|
|
dzyk
Legendary
Offline
Activity: 1792
Merit: 1028
dzyk.ru
|
|
December 28, 2018, 12:32:43 PM |
|
fxpc, Саша, ну ты зачем kzv ругаешь так жеско))) он вон сколько кода написал... чуть дизайн проработать, обьемы подбить и заработает биржа как надо)))
|
|
|
|
fxpc
Sr. Member
Offline
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
|
|
December 28, 2018, 05:50:35 PM Last edit: December 28, 2018, 06:26:51 PM by fxpc |
|
У тебя какая-то странная реакция. С чего ты это взял что я его ругаю? Всего лишь высказал своё мнение про выбранный инструмент. Код с дизайном здесь вовсе ни при чём.
|
|
|
|
kzv (OP)
Legendary
Offline
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
|
|
December 28, 2018, 06:09:52 PM |
|
Либо я чего-то не понял, либо ты себе противоречишь, когда пишешь что перевёл базу данных в отдельный процесс и скорость стала получше. Если у биржи мало клиентов, то конечно с нагрузкой справится любая БД. Не знаю специфику запросов твоей биржи, но SQLite точно сливает enterprise решениям при высокой нагрузке и даже при низкой, когда ей сопутствует большое количество writes.
Я не противоречу. Увеличение скорости это мое субъективное мнение. Технических замеров до и после я не проводил. Однако техническая логика подсказывает: чтение/запись в сокетах обязано быть существенно медленней, чем чтение/запись в оперативке. Мифы про якобы тормознутость SQLite распространяют те, кто ей не пользуется. Операции записи там тормозят только если их не оборачивать в транзакцию. Если все делать правильно, то SQLite если не уделает, то уж точно не отстанет от любых постгре и прочих мускулей.
|
|
|
|
fxpc
Sr. Member
Offline
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
|
|
December 28, 2018, 06:55:12 PM |
|
Либо я чего-то не понял, либо ты себе противоречишь, когда пишешь что перевёл базу данных в отдельный процесс и скорость стала получше. Если у биржи мало клиентов, то конечно с нагрузкой справится любая БД. Не знаю специфику запросов твоей биржи, но SQLite точно сливает enterprise решениям при высокой нагрузке и даже при низкой, когда ей сопутствует большое количество writes.
Я не противоречу. Увеличение скорости это мое субъективное мнение. Технических замеров до и после я не проводил. Однако техническая логика подсказывает: чтение/запись в сокетах обязано быть существенно медленней, чем чтение/запись в оперативке. Мифы про якобы тормознутость SQLite распространяют те, кто ей не пользуется. Операции записи там тормозят только если их не оборачивать в транзакцию. Если все делать правильно, то SQLite если не уделает, то уж точно не отстанет от любых постгре и прочих мускулей. В этом моменте техническая логика встречается с объективной реальностью и нюансами. Я более чем уверен, что в серверном приложении выделение БД в отдельный процесс повышает производительность, поэтому ты неспроста это на глаз определил. Я не говорил про тормознутость, речь шла о том что под нагрузкой по сети он сдохнет раньше чем enterprise. У каждого инструмента своя ниша. SQLite хорош для локального применения и его используют преимущественно для данного кейса. Совпадение? Не думаю. Хочешь сам ходить по граблям, чтобы в итоге прийти к enterprise решениям - дело хозяйское, моё дело предложить.
|
|
|
|
kzv (OP)
Legendary
Offline
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
|
|
December 28, 2018, 07:01:20 PM |
|
Я не говорил про тормознутость, речь шла о том что под нагрузкой по сети он сдохнет раньше чем enterprise.
SQlite вообще сама по себе не умеет с сетью работать по определению. Ну нет там в коде сокетов от слова вообще. Чтобы заставить ее работать как отдельный сервер, я написал прокладку на node.js В том, что нода сдохнет под нагрузкой я лично сильно сомневаюсь - нгинкс сдохнет раньше, про апач вообще молчу.
|
|
|
|
fxpc
Sr. Member
Offline
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
|
|
December 28, 2018, 07:32:00 PM |
|
Я не говорил про тормознутость, речь шла о том что под нагрузкой по сети он сдохнет раньше чем enterprise.
SQlite вообще сама по себе не умеет с сетью работать по определению. Ну нет там в коде сокетов от слова вообще. Чтобы заставить ее работать как отдельный сервер, я написал прокладку на node.js В том, что нода сдохнет под нагрузкой я лично сильно сомневаюсь - нгинкс сдохнет раньше, про апач вообще молчу. Правильно не умеет, потому что она для этого не предназначена, именно это и является её ахилесовой пятой. Она не благодаря нагрузке превышающей возможности nginx сдохнет, а благодаря своей архитектуре, скорее всего заблокируется и напрочь отстанет от запросов, но это не точно.
|
|
|
|
kzv (OP)
Legendary
Offline
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
|
|
December 28, 2018, 07:54:37 PM |
|
Правильно не умеет, потому что она для этого не предназначена, именно это и является её ахилесовой пятой. Она не благодаря нагрузке превышающей возможности nginx сдохнет, а благодаря своей архитектуре, скорее всего заблокируется и напрочь отстанет от запросов, но это не точно.
Она предназначена быть встроенной в процесс. Внутри процесса она в своей стихии и потому уделает кого угодно - доказано 100500 продуктами которые ее используют в качестве встроенной бд. Теперь как она работает у меня? Внезапно, она работает как встроенная в процесс сервера бд. То есть sqlite у меня работает именно так, как она и должна работать по своей архитектуре. Сервер же написан на ноде, а значит не сдохнет ни при какой нагрузке 146%. Так что если где и может возникнуть затык по скорости, дак это только в вызывающем клиенте (биржа, нгинкс и прочие апачи), а в сервере sqlite я уверен.
|
|
|
|
fxpc
Sr. Member
Offline
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
|
|
December 28, 2018, 08:01:48 PM |
|
Правильно не умеет, потому что она для этого не предназначена, именно это и является её ахилесовой пятой. Она не благодаря нагрузке превышающей возможности nginx сдохнет, а благодаря своей архитектуре, скорее всего заблокируется и напрочь отстанет от запросов, но это не точно.
Она предназначена быть встроенной в процесс. Внутри процесса она в своей стихии и потому уделает кого угодно - доказано 100500 продуктами которые ее используют в качестве встроенной бд. Теперь как она работает у меня? Внезапно, она работает как встроенная в процесс сервера бд. То есть sqlite у меня работает именно так, как она и должна работать по своей архитектуре. Сервер же написан на ноде, а значит не сдохнет ни при какой нагрузке 146%. Так что если где и может возникнуть затык по скорости, дак это только в вызывающем клиенте (биржа, нгинкс и прочие апачи), а в сервере sqlite я уверен. Ещё раз перечитай что я тебе написал. При определённом характере нагрузки кролик сам себе откусит голову, это не проблема SQLite, просто у неё такая архитектура и она не предназначена для твоего кейса.
|
|
|
|
kzv (OP)
Legendary
Offline
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
|
|
December 28, 2018, 08:06:06 PM |
|
При определённом характере нагрузки кролик сам себе откусит голову, это не проблема SQLite, просто у неё такая архитектура и она не предназначена для твоего кейса.
...но это не точно )) На сегодняшний день я лично не вижу явных проблем с использованием sqlite в качестве бухгалтерской книги. Когда увижу, буду думать как с этим жить дальше.
|
|
|
|
dzyk
Legendary
Offline
Activity: 1792
Merit: 1028
dzyk.ru
|
|
December 31, 2018, 08:14:50 AM |
|
походу fxpc просто троллит.... никаких веских аргументов...
|
|
|
|
|