10 марта 2016, 8:03:30 PM   # 1
 
 
Сообщения: 532
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Из: https://en.wikipedia.org/wiki/LevelDB

LevelDB широко известен ненадежны и базы данных, которыми он управляет склонны к коррупции. [Править] Подробный анализ уязвимостей в дизайне LevelDB были выполнены учеными из Университета штата Висконсин [14] [15], подтверждающие множественные причины плохой надежности LevelDB в. Анализ показывает, что LevelDB консистенция зависит от файловых операций, являющихся атомного и сохранения порядка, но в реальном мире файловых системы не обеспечивают гарантии для любого из них.

Примечание: Нейтральность оспаривается.

Мысли?
classicsucks сейчас офлайн Пожаловаться на classicsucks   Ответить с цитированием Мультицитирование сообщения от classicsucks Быстрый ответ на сообщение classicsucks


Как заработать Биткоины?
Без вложений. Не майнинг.


10 марта 2016, 8:15:13 PM   # 2
 
 
Сообщения: 1246
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

Получил 1806 Биткоинов
Реальная история.





LevelDB глупо это одна из главных причин того, что люди должны проиндексировать на Bitcoin Ядро падает. Там были предложения, чтобы заменить его, но до сих пор нет никаких планов на этом. Однако люди работают на использовании различных баз данных в Bitcoin Ядра, и те, которые реализуются и испытаны.
achow101 сейчас офлайн Пожаловаться на achow101   Ответить с цитированием Мультицитирование сообщения от achow101 Быстрый ответ на сообщение achow101

10 марта 2016, 9:10:42 PM   # 3
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

LevelDB глупо это одна из главных причин того, что люди должны проиндексировать на Bitcoin Ядро падает. Там были предложения, чтобы заменить его, но до сих пор нет никаких планов на этом. Однако люди работают на использовании различных баз данных в Bitcoin Ядра, и те, которые реализуются и испытаны.

Может быть, самый надежный DB не DB вообще? Используйте эффективно кодироваться только для чтения файлов, которые могут быть непосредственно отображены в карте памяти.



https://bitco.in/forum/forums/iguana.23/

Джеймс
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

10 марта 2016, 10:54:04 PM   # 4
 
 
Сообщения: 266
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

Мысли?

На мой взгляд LevelDB лучше, чем предыдущий Berkley DB Bitcoin используется.

Посмотрите на кошельках Берки DB! Они стали коррумпированной, потому что некоторые Mac OS парень переименовал свою wallet.dat в то время как Bitcoin был запущен.

Да, мы знаем, что Mac файловых систем являются куча дерьма.


дБ Уровень выглядит как простое хранилище ключ значение, так что я не понимаю, что именно делали Googol инженеры завинтить.
Watashi-kokoto сейчас офлайн Пожаловаться на Watashi-kokoto   Ответить с цитированием Мультицитирование сообщения от Watashi-kokoto Быстрый ответ на сообщение Watashi-kokoto

10 марта 2016, 11:06:13 PM   # 5
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

Мысли?

На мой взгляд LevelDB лучше, чем предыдущий Berkley DB Bitcoin используется.

Посмотрите на кошельках Берки DB! Они стали коррумпированной, потому что некоторые Mac OS парень переименовал свою wallet.dat в то время как Bitcoin был запущен.

Да, мы знаем, что Mac файловых систем являются куча дерьма.


дБ Уровень выглядит как простое хранилище ключ значение, так что я не понимаю, что именно делали Googol инженеры завинтить.
зачем использовать БД для инвариантного набора данных?
После N блоков, изменение blockchain оленьей кожи, верно?

Таким образом, нет никакой потребности в способности выполнять общие операции БД. Есть места, где DB является правильным, но это как сравнение добычи процессора для добычи ASIC.

Процессор может выполнять любой вид Calcs, как БД может делать какое-либо операции с данными
СИС делает одну вещь, но очень быстро. Жестко заданного набора данных одно и то же. Думайте об этом как ASIC аналог БД.

так что ничего плохого в БД вообще, вы просто не можете не сравнить ASIC для CPU
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

11 марта 2016, 1:06:22 AM   # 6
 
 
Сообщения: 1988
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

зачем использовать БД для инвариантного набора данных?
Это звучит как вопрос экзамена для СУБД 101 курса.

1) независимость логических данных от физической памяти
2) совместное использование набора данных между задачами и машинами
3) быстрая проверка целостности
4) оптимизация способа хранения, чтобы соответствовать модели доступа
5) поддержание целостности транзакций с соответствующими наборами данных и процессов
6) дробное / добавочное резервное копирование / восстановление при доступе программного обеспечения онлайн
7) поддержка для специальных запросов без необходимости написания программного обеспечения
8) легкость интеграции с новыми или несвязанными пакетами программного обеспечения
9) соблюдение стандартов учета и аудита
10) проще сбор статистических данных о шаблонах доступа

Я думаю, что эти 10 ответов будут достаточно хорошо для А или А-, может быть, B + в очень требовательный курсе / школе.
2112 сейчас офлайн Пожаловаться на 2112   Ответить с цитированием Мультицитирование Сообщения от 2112 Быстрый ответ на сообщение 2112

11 марта 2016, 1:17:40 AM   # 7
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

LevelDB глупо это одна из главных причин того, что люди должны проиндексировать на Bitcoin Ядро падает. Там были предложения, чтобы заменить его, но до сих пор нет никаких планов на этом. Однако люди работают на использовании различных баз данных в Bitcoin Ядра, и те, которые реализуются и испытаны.

Это неверно.

LevelDB нужен "Уровень интерфейса файловой системы", Он не приходит с одним для окон; когда LevelDB используется в Chrome использует специальный хром специального API, чтобы поговорить с файловой системой. Вкладчик предоставил окно слой для Bitcoin, который является то, что позволило Bitcoin использовать LevelDB в первую очередь.

Этот разделительный слой окна файловой системы неверен: это не удалось очистить на диск во всех точках которой он должен. Он быстро фиксируется, как только кто-то принес инструкции по искусственному оплодотворению Владимира, и он воспроизводил его. Там было много faffing о замене его, в основном, люди, которые не способствуют часто core-- на мой взгляд, это пример плохого груза культа "инжиниринг" где вместо реальных инженерных людей шаблону матч словечки и клей черные ящики вместе: "Я HURD вам нужна база данных. Однажды кто-то сказал мне, что MYCROSAFT сиквела ЭТО БОЛЬШОЙ DATABASE. ИМЕЕТ WEBSCALE", Когда фактические инженеры системы обручились, проблема была быстро исправлена.

Это особенно раздражает, потому что LevelDB не является универсальным реляционной базой данных, это узкоспециализированный транзакционной магазин ключ / значение. LevelDB гораздо больше как эффективный диск спинок реализации MAP, чем это, как все, что вы обычно называете базу данных. Большинство других "база данных" Системы люди предполагают, не в течение трех порядков в исполнении для нашего конкретного очень узкого использования. Очевидный alternatives-- как LMDB имеют другие ограничения (в частности, LMDB должны MMAP файлов, которые в основном, позволяют использовать его на 32 битом Системы-- стыда, потому что мне нравится LMDB много для одной и той же ниши LevelDB охватывает, LevelDB также имеет большую коррупцию обнаружение, для нас важно, потому что мы не хотим, чтобы неправильно отклонить цепь из-за повреждения файловой системы).

Я думаю, что это более вероятно, что Bitcoin ядро ​​будет в конечном итоге перейти на структуру пользовательских данных, чем другие "база данных" (Возможно своп с LMDB, если они когда-либо поддержки не-MMAP операции ... возможно); так как это было бы в принципе быть требованием для набора обязательств производительности utxo.

Большое количество этих отчетов о коррупции были также вызваны антивирусным программным обеспечением случайно _deleting_ файлы из-под Bitcoin Core. Оказывается, что есть вирус "подписи" что долго, как короткие, как 16 байтов ... и AV программы избежать удаления случайных файлов по всей системе пользователей с помощью набора сумасшедших эвристики, как согласование расширения, которые не удалось исключить информацию Bitcoin (хотя я уверен, что фактические вирусы не имеют никаких проблем злоупотребление этими эвристики, чтобы избежать обнаружения). Ядро реализована отбеливающая схема, запутать сохраненное состояние для того, чтобы избежать этих проблем или любой другой потенциал для враждебных данных blockchain взаимодействовать с фантастическими файловой системой или хранением ошибок.

Сейчас это очень трудно повредить chainstate на Windows, в Bitcoin Ядра 0.12+. Там еще могут быть некоторые примеры ошибок угловых, но теперь они достаточно редки, что их трудно отличить от сломанной аппаратных / плохих водителей, которые ненадлежащим образом кэш записи или иным образом поврежденные data-- вопросы, которые ни один здравомыслящий значение ключа магазин не может действительно иметь дело с. Если вы в состоянии воспроизвести коррупцию, как это, я бы очень хотел услышать от вас.

Мы страдали немного, как и многие другие проекты Open Source делают - в том, что сравнительно мало квалифицированных разработчиков с открытым исходным кодом использовать ОС Windows (и, что немаловажно, некоторые _continue_ использовать окна, как только они свисающие с пользователями / BSD Linux, если ничего иначе они в конечном итоге переход к Mac) - таким образом, мы дополнительные зависит от _good_ отчетов неприятности от пользователей Windows, когда есть проблема, которая для Windows конкретных ...

зачем использовать БД для инвариантного набора данных?
После N блоков, изменение blockchain оленьей кожи, верно?
Bitcoin ядро ​​не хранит blockchain в базе данных (или LevelDB) и никогда не имеет. Blockchain хранится в предварительно выделено дописать только файлы на диске в упакованном виде необработанных блоков в том же формате, они отправленного по сети. Блоки, которые получают осиротевшие просто оставили позади (там достаточно мало, что не имеет особого значения.


[Лекция о общих причинах, чтобы использовать RDBMS]
Ни один из них не применимы к хранению диска поддерживается карта, хранящей высокой степенью сжатия информации о состоянии на основе криптографического алгоритма на основе консенсуса, но хорошие моменты в целом.
gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

11 марта 2016, 1:28:26 AM   # 8
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

Bitcoin ядро ​​не хранит blockchain в базе данных (или LevelDB) и никогда не имеет. Blockchain хранится в предварительно выделено дописать только файлы на диске в упакованном виде необработанных блоков в том же формате, они отправленного по сети. Блоки, которые получают осиротевшие просто оставили позади (там достаточно мало, что не имеет особого значения.

Итак, что же БД используется? Будет ли все еще работать без БД?

При изменении набора данных разве все поисковые таблицы могут быть зашиты
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

11 марта 2016, 1:33:30 AM   # 9
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

зачем использовать БД для инвариантного набора данных?
Это звучит как вопрос экзамена для СУБД 101 курса.

1) независимость логических данных от физической памяти
2) совместное использование набора данных между задачами и машинами
3) быстрая проверка целостности
4) оптимизация способа хранения, чтобы соответствовать модели доступа
5) поддержание целостности транзакций с соответствующими наборами данных и процессов
6) дробное / добавочное резервное копирование / восстановление при доступе программного обеспечения онлайн
7) поддержка для специальных запросов без необходимости написания программного обеспечения
легкость интеграции с новыми или несвязанными пакетами программного обеспечения
9) соблюдение стандартов учета и аудита
10) проще сбор статистических данных о шаблонах доступа

Я думаю, что эти 10 ответов будут достаточно хорошо для А или А-, может быть, B + в очень требовательный курсе / школе.

Хорошо, вы можете получить A

Однако, отображенная на память файлов имеют много одних и те же преимущества, вы перечисляете:

1) независимость логических данных от физической памяти - да
2) совместное использование набора данных между задачами и машины - да (вам нужны обе формы порядком байт)
3) быстрая проверка целостности - да, даже быстрее, так как один раз проверить, нет необходимости, чтобы проверить еще раз
4) оптимизация способа хранения, чтобы соответствовать модели доступа - да, что это именно то, что было сделано
5) поддержание целостности транзакций с соответствующими наборами данных и процессов - да
6) дробное / инкрементное резервное копирование / восстановление программного обеспечения при доступе к онлайн - да

7) поддержка для специальных запросов без необходимости написания программного обеспечения - нет
легкость интеграции с новыми или несвязанными пакетами программного обеспечения - нет
9) соблюдение стандартов учета и аудита - не уверен
10) проще сбор статистических данных о модели доступа - не без пользовательского кода

Так что это зависит от того, от 7 до 10 превзойдут выгоды, и если имеются ресурсы, чтобы получить его работу

Джеймс
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

11 марта 2016, 10:08:06 AM   # 10
 
 
Сообщения: 532
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

Спасибо всем за информированные ответы.

Представляется, что основная файловая система является подстановочной при использовании LevelDB. Вероятно, он был разработан и испытан на вершине ext3 или ext4 ... Кто знает, что произойдет, если один использует Btrfs или любой другой ...

Я полагаю, что производительность будет убита, имеющими промежуточный слой кэширования записи?
classicsucks сейчас офлайн Пожаловаться на classicsucks   Ответить с цитированием Мультицитирование сообщения от classicsucks Быстрый ответ на сообщение classicsucks

11 марта 2016, 10:58:31 AM   # 11
 
 
Сообщения: 464
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

LevelDB глупо это одна из главных причин того, что люди должны проиндексировать на Bitcoin Ядро падает. Там были предложения, чтобы заменить его, но до сих пор нет никаких планов на этом. Однако люди работают на использовании различных баз данных в Bitcoin Ядра, и те, которые реализуются и испытаны.

Может быть, самый надежный DB не DB вообще? Используйте эффективно кодироваться только для чтения файлов, которые могут быть непосредственно отображены в карте памяти.



https://bitco.in/forum/forums/iguana.23/

Джеймс

LevelDB используется для хранения набора UTXO. Как это только для чтения?
hhanh00 сейчас офлайн Пожаловаться на hhanh00   Ответить с цитированием Мультицитирование сообщения от hhanh00 Быстрый ответ на сообщение hhanh00

11 марта 2016, 11:13:52 AM   # 12
 
 
Сообщения: 173
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

LevelDB, безусловно, о слабой консистенции ради спектакля, так же как и большинство баз данных NoSQL.

Blockchain системы, вероятно, потребуется для версионированных неизменных баз данных с возможностью отката и эффективной очисткой старых версий в фоновом режиме. Там нет известных реализаций вокруг, хотя.
kushti сейчас офлайн Пожаловаться на kushti   Ответить с цитированием Мультицитирование сообщения от kushti Быстрый ответ на сообщение kushti

11 марта 2016, 1:37:26 PM   # 13
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

LevelDB глупо это одна из главных причин того, что люди должны проиндексировать на Bitcoin Ядро падает. Там были предложения, чтобы заменить его, но до сих пор нет никаких планов на этом. Однако люди работают на использовании различных баз данных в Bitcoin Ядра, и те, которые реализуются и испытаны.

Может быть, самый надежный DB не DB вообще? Используйте эффективно кодироваться только для чтения файлов, которые могут быть непосредственно отображены в карте памяти.



https://bitco.in/forum/forums/iguana.23/

Джеймс

LevelDB используется для хранения набора UTXO. Как это только для чтения?

UTXO набор попадет в неперезаписываемую категории. После ввода затрачивается, вы не можете провести его снова. Разница с множеством UTXO объясняется здесь: https://bitco.in/forum/threads/30mb-utxo-bitmap-uncompressed.941/

Таким образом, вы можете рассчитать OR'able изображения для каждого пучка параллельно (как только все его предыдущие пакеты есть). Затем, чтобы создать текущий набор utxo, или растровые изображения вместе.

Что будет практически оставаться нестабильной является растровый, но наложение растровых изображений для каждого пучка только для чтения. Это делает UTXO проверить дело, чтобы найти индекс Vout и проверить немного.

Джеймс
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

11 марта 2016, 1:51:06 PM   # 14
 
 
Сообщения: 173
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

Blockchain системы, вероятно, потребуется для версионированных неизменных баз данных с возможностью отката и эффективной очисткой старых версий в фоновом режиме. Там нет известных реализаций вокруг, хотя.

Ну на самом деле мы полуготовность решение, что используется в нашей открытой модульной структуре blockchain Scorex ( https://github.com/ScorexProject/Scorex ). Мы можем воплощать его и сделать Pull-запрос на Bitcoinj если некоторые Java DEV хотели бы помочь с Java части
kushti сейчас офлайн Пожаловаться на kushti   Ответить с цитированием Мультицитирование сообщения от kushti Быстрый ответ на сообщение kushti

12 марта 2016, 2:30:27 AM   # 15
 
 
Сообщения: 464
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

LevelDB глупо это одна из главных причин того, что люди должны проиндексировать на Bitcoin Ядро падает. Там были предложения, чтобы заменить его, но до сих пор нет никаких планов на этом. Однако люди работают на использовании различных баз данных в Bitcoin Ядра, и те, которые реализуются и испытаны.

Может быть, самый надежный DB не DB вообще? Используйте эффективно кодироваться только для чтения файлов, которые могут быть непосредственно отображены в карте памяти.



https://bitco.in/forum/forums/iguana.23/

Джеймс

LevelDB используется для хранения набора UTXO. Как это только для чтения?

UTXO набор попадет в неперезаписываемую категории. После ввода затрачивается, вы не можете провести его снова. Разница с множеством UTXO объясняется здесь: https://bitco.in/forum/threads/30mb-utxo-bitmap-uncompressed.941/

Таким образом, вы можете рассчитать OR'able изображения для каждого пучка параллельно (как только все его предыдущие пакеты есть). Затем, чтобы создать текущий набор utxo, или растровые изображения вместе.

Что будет практически оставаться нестабильной является растровый, но наложение растровых изображений для каждого пучка только для чтения. Это делает UTXO проверить дело, чтобы найти индекс Vout и проверить немного.

Джеймс

Не уверен, что если мы говорим о том же. После вашей ссылки, вы, кажется, описываете внутреннюю структуру данных, используемую в блоке проводником, который не обязательно является оптимальным для узла Bitcoin.
В частности, вы используете 6 байт локатора. Учитывая новые входящие сделки, которая может провести любой utxo (хэш + Vout), вам нужно сопоставить его локатор? И если да, то как это делается?

hhanh00 сейчас офлайн Пожаловаться на hhanh00   Ответить с цитированием Мультицитирование сообщения от hhanh00 Быстрый ответ на сообщение hhanh00

12 марта 2016, 3:21:32 AM   # 16
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

LevelDB глупо это одна из главных причин того, что люди должны проиндексировать на Bitcoin Ядро падает. Там были предложения, чтобы заменить его, но до сих пор нет никаких планов на этом. Однако люди работают на использовании различных баз данных в Bitcoin Ядра, и те, которые реализуются и испытаны.

Может быть, самый надежный DB не DB вообще? Используйте эффективно кодироваться только для чтения файлов, которые могут быть непосредственно отображены в карте памяти.



https://bitco.in/forum/forums/iguana.23/

Джеймс

LevelDB используется для хранения набора UTXO. Как это только для чтения?

UTXO набор попадет в неперезаписываемую категории. После ввода затрачивается, вы не можете провести его снова. Разница с множеством UTXO объясняется здесь: https://bitco.in/forum/threads/30mb-utxo-bitmap-uncompressed.941/

Таким образом, вы можете рассчитать OR'able изображения для каждого пучка параллельно (как только все его предыдущие пакеты есть). Затем, чтобы создать текущий набор utxo, или растровые изображения вместе.

Что будет практически оставаться нестабильной является растровый, но наложение растровых изображений для каждого пучка только для чтения. Это делает UTXO проверить дело, чтобы найти индекс Vout и проверить немного.

Джеймс

Не уверен, что если мы говорим о том же. После вашей ссылки, вы, кажется, описываете внутреннюю структуру данных, используемую в блоке проводником, который не обязательно является оптимальным для узла Bitcoin.
В частности, вы используете 6 байт локатора. Учитывая новые входящие сделки, которая может провести любой utxo (хэш + Vout), вам нужно сопоставить его локатор? И если да, то как это делается?


игуана является Bitcoin узлом, который происходит обновление блока уровня исследователя набора данных.
Структуры данных оптимизированы для параллельного доступа, поэтому поиски многоядерных могут быть использованы
Однако даже с одним ядром поиска линейно (в обратном направлении), он довольно быстро найти любой TXID

Каждый пучок 2000 файлов имеет жёстко прописанные хэш-таблицу для всех TXID в нем, так что это дело делать хэш-поиск, пока не будет найден. Я не имею тайминги полной обработки полный блок еще, но я не ожидаю, что это займет больше, чем несколько секунд, чтобы обновить все VINs и vouts

поскольку TXID являются уже высокой энтропией, нет необходимости делать дополнительный хэш, поэтому я XOR все 4 64-разрядное Интс на TXID вместе, чтобы создать индекс в открытую хэш-таблицу, которая создается, чтобы быть не более чем наполовину полный, поэтому он будет найти матч в очень нескольких итераций. Поскольку все отображенные на память, после первоначального доступа, чтобы поменять его, каждый поиск займет меньше микросекунды
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

12 марта 2016, 9:22:36 AM   # 17
HyC
 
 
Сообщений: 83
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

LevelDB нужен "Уровень интерфейса файловой системы", Он не приходит с одним для окон; когда LevelDB используется в Chrome использует специальный хром специального API, чтобы поговорить с файловой системой. Вкладчик предоставил окно слой для Bitcoin, который является то, что позволило Bitcoin использовать LevelDB в первую очередь.

Этот разделительный слой окна файловой системы неверен: это не удалось очистить на диск во всех точках которой он должен. Он быстро фиксируется, как только кто-то принес инструкции по искусственному оплодотворению Владимира, и он воспроизводил его. Там было много faffing о замене его, в основном, люди, которые не способствуют часто core-- на мой взгляд, это пример плохого груза культа "инжиниринг" где вместо реальных инженерных людей шаблону матч словечки и клей черные ящики вместе: "Я HURD вам нужна база данных. Однажды кто-то сказал мне, что MYCROSAFT сиквела ЭТО БОЛЬШОЙ DATABASE. ИМЕЕТ WEBSCALE", Когда фактические инженеры системы обручились, проблема была быстро исправлена.

Это, кажется, игнорировать большое количество не-Windows связанных вхождений коррупции.

котировка
Это особенно раздражает, потому что LevelDB не является универсальным реляционной базой данных, это узкоспециализированный транзакционной магазин ключ / значение. LevelDB гораздо больше как эффективный диск спинок реализации MAP, чем это, как все, что вы обычно называете базу данных. Большинство других "база данных" Системы люди предполагают, не в течение трех порядков в исполнении для нашего конкретного очень узкого использования. Очевидный alternatives-- как LMDB имеют другие ограничения (в частности, LMDB должны MMAP файлов, которые в основном, позволяют использовать его на 32 битом Системы-- стыда, потому что мне нравится LMDB много для одной и той же ниши LevelDB охватывает, LevelDB также имеет большую коррупцию обнаружение, для нас важно, потому что мы не хотим, чтобы неправильно отклонить цепь из-за повреждения файловой системы).

Я думаю, что это более вероятно, что Bitcoin ядро ​​будет в конечном итоге перейти на структуру пользовательских данных, чем другие "база данных" (Возможно своп с LMDB, если они когда-либо поддержки не-MMAP операции ... возможно); так как это было бы в принципе быть требованием для набора обязательств производительности utxo.

LevelDB не транзакционный хранилище данных, он не поддерживает полную семантику ACID. В нем нет изоляции, в первую очередь, и ее атомарность функции на самом деле не надежны. Ни одна система хранения, которая опирается на несколько файлов для хранения может предложить истинную атомарность - то же самое применяется к BerkeleyDB тоже.

В то же время, несмотря опираясь на ттар, LMDB работает отлично на 32-битных системах. И в отличие от LevelDB, LMDB полностью поддерживается на Windows. (Кроме того, в отличие от LevelDB, LMDB есть * полностью поддерживается. * - LevelDB не активно поддерживается больше)

котировка
Большое количество этих отчетов о коррупции были также вызваны антивирусным программным обеспечением случайно _deleting_ файлы из-под Bitcoin Core. Оказывается, что есть вирус "подписи" что долго, как короткие, как 16 байтов ... и AV программы избежать удаления случайных файлов по всей системе пользователей с помощью набора сумасшедших эвристики, как согласование расширения, которые не удалось исключить информацию Bitcoin (хотя я уверен, что фактические вирусы не имеют никаких проблем злоупотребление этими эвристики, чтобы избежать обнаружения). Ядро реализована отбеливающая схема, запутать сохраненное состояние для того, чтобы избежать этих проблем или любой другой потенциал для враждебных данных blockchain взаимодействовать с фантастическими файловой системой или хранением ошибок.

Сейчас это очень трудно повредить chainstate на Windows, в Bitcoin Ядра 0.12+. Там еще могут быть некоторые примеры ошибок угловых, но теперь они достаточно редки, что их трудно отличить от сломанной аппаратных / плохих водителей, которые ненадлежащим образом кэш записи или иным образом поврежденные data-- вопросы, которые ни один здравомыслящий значение ключа магазин не может действительно иметь дело с. Если вы в состоянии воспроизвести коррупцию, как это, я бы очень хотел услышать от вас.

Мы страдали немного, как и многие другие проекты Open Source делают - в том, что сравнительно мало квалифицированных разработчиков с открытым исходным кодом использовать ОС Windows (и, что немаловажно, некоторые _continue_ использовать окна, как только они свисающие с пользователями / BSD Linux, если ничего иначе они в конечном итоге переход к Mac) - таким образом, мы дополнительные зависит от _good_ отчетов неприятности от пользователей Windows, когда есть проблема, которая для Windows конкретных ...
HyC сейчас офлайн Пожаловаться на HyC   Ответить с цитированием Мультицитирование сообщения от HyC Быстрый ответ на сообщение HyC

12 марта 2016, 5:40:29 PM   # 18
 
 
Сообщения: 1148
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

Итак, что же БД используется? Будет ли все еще работать без БД?

Все блоки сохраняются в том же формате, что они получили, а добавлять только файлы. Есть Undo (реверс) файлы, которые хранятся отдельно (и они присоединять только файл тоже).

Вы можете взять UTXO установить, как для блока 400000, а затем применить файл отката для блока 400000, и вы получите состояние для блока 399,999.

Это означает, что множество UTXO может быть отстранился во время цепной REORG. Вы используете отмены (реверс) файлы на шаг назад, пока не попали в вилке, а затем двигаться вперед вдоль новой вилки.

В базе данных хранится набор UTXO, который соответствует chaintip в любой момент времени. Это только когда-либо изменить, чтобы добавить / удалить блок атомарно.

Каждый новый блок атомарно обновляет набор UTXO.

Блок-хеши сопоставляются (типа «B» запись):
  • предыдущая хэш
  • высота блока
  • какой файл хранится в
  • Файл смещения для блока в блоке *****. Дат
  • смещение в файл для отката данных в обороте *****. Дат
  • блок версия
  • корень Merkle
  • отметка времени
  • мишень (биты)
  • данное время
  • положение дел (Заголовки подтверждено, блок получен, блок подтверждено и т.д.)
  • Количество транзакций)

Каждый ключ предварительно затрачиваемая на код чтобы указать, какой тип записи и все записи хранятся в одной базе данных.

DB_COINS = 'с';
DB_BLOCK_FILES = 'е';
DB_TXINDEX = 'T';
DB_BLOCK_INDEX = 'B';

C: Карты TXID для неизрасходованных выходов для этой транзакции
е: индексный файл Карты Информация об этом файле
т: Карты TXID к месту сделки (номер файла + смещение)
б: Карты блок хэш к информации заголовка блока (см выше)

Поле «т» не все сделки, если txindex не включен.

Эти одиночные записи только поле (я думаю):

DB_BEST_BLOCK = 'В';
DB_FLAG = 'F';
DB_REINDEX_FLAG = 'R';
DB_LAST_BLOCK = 'L';
TierNolan сейчас офлайн Пожаловаться на TierNolan   Ответить с цитированием Мультицитирование сообщения от TierNolan Быстрый ответ на сообщение TierNolan

12 марта 2016, 6:19:52 PM   # 19
 
 
Сообщения: 266
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

Все блоки сохраняются ....

Действительно интересная информация, спасибо
Watashi-kokoto сейчас офлайн Пожаловаться на Watashi-kokoto   Ответить с цитированием Мультицитирование сообщения от Watashi-kokoto Быстрый ответ на сообщение Watashi-kokoto

13 марта 2016, 4:29:33 AM   # 20
 
 
Сообщения: 1988
Цитировать по имени
цитировать ответ
по умолчанию Re: Надежность LevelDB?

Однако, отображенная на память файлов имеют много одних и те же преимущества, вы перечисляете:

1) независимость логических данных от физической памяти - да
2) совместное использование набора данных между задачами и машины - да (вам нужны обе формы порядком байт)
3) быстрая проверка целостности - да, даже быстрее, так как один раз проверить, нет необходимости, чтобы проверить еще раз
4) оптимизация способа хранения, чтобы соответствовать модели доступа - да, что это именно то, что было сделано
5) поддержание целостности транзакций с соответствующими наборами данных и процессов - да
6) дробное / инкрементное резервное копирование / восстановление программного обеспечения при доступе к онлайн - да

7) поддержка для специальных запросов без необходимости написания программного обеспечения - нет
легкость интеграции с новыми или несвязанными пакетами программного обеспечения - нет
9) соблюдение стандартов учета и аудита - не уверен
10) проще сбор статистических данных о модели доступа - не без пользовательского кода

Так что это зависит от того, от 7 до 10 превзойдут выгоды, и если имеются ресурсы, чтобы получить его работу

Джеймс
Я действительно не хочу быть обескураживающим для вас. Вы делаете очень творческие и инновационные работы, но вы знаете, меньше нуля о базах данных, и это будет мешать вам. Вы пишете как самоучка или, может быть, вы пошли в какой-то очень плохой школе.

1) не ММАП () - не эды файлов, которые используются вами не обеспечивает независимость расположения физического хранения. Она фиксируется в вашем коде и в вашем предлагаемом использовании файловой системы. Даже не простые задачи, такие как добавление дополнительных дисковых томов с большим количеством свободного пространства, а в Интернете.

2) она не кажется, что ваш код делает любой замок, так что в данный момент вы не можете даже сделать обмен на одном хосте. Общий ММАП () по NFS (или MapViewOfFile () по SMB) только для головорезов.

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

4) к сожалению, вы застряли в колее исключительно тестирования первоначальной синхронизации. Это очень нерепрезентативная шаблон доступа. Даже не-программисты в другом потоке знают об этой проблеме. Это причина, почему профессиональные системы баз данных имеют отдельные инструменты для начальной загрузки (как SQL * Loader для Oracle или BULK INSERT в стандартном SQL).

5) Я не верю, что вы знаете, что вы говорите. Я уверен, что вы никогда не слышали https://en.wikipedia.org/wiki/Two-phase_commit_protocol и не мог назвать ни одного https://en.wikipedia.org/wiki/Transaction_processing_system Спасти твою жизнь.

6) Я не мог найти никаких следов поддержки для блокировки или инкрементного резервного копирования / восстановления в вашем коде. Лично вы похожи на кого-то, кто редко создает резервные копии, даже реже восстанавливает и проверяет. Даже любители, но опытные не-программисты, кажется, более осведомлено о живых резервном копировании вопросов.

Так что не 7/10 или даже 6/10. Это 0/10 с большим минусом для получения пункта 3) так сильно неправильно.

Опять же, я не хочу быть обескураживающим для вашего проекта программирования, хотя я не в полной мере понять его. Только, пожалуйста, не пишите о чем-то у вас нет понимания.

Такие люди, как Грегори Максвелл, Майк Херн или Питер Тодд получают деньги, чтобы делать вид, не понять. Старая цитата:

Цитата: Upton Sinclair
Трудно получить человек, чтобы понять что-то, когда его зарплата зависит от его, не понимая его!
2112 сейчас офлайн Пожаловаться на 2112   Ответить с цитированием Мультицитирование Сообщения от 2112 Быстрый ответ на сообщение 2112



Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW