Кто вам сказал что я что-то собирался объяснять вам?
Проблема-то в том, что Вы не умеете объяснять вообще
Topic: Теория графов и наделов (Read 1317 times)
Проблема-то в том, что Вы не умеете объяснять вообще
rPman, бегите из этого треда. Я вас прикрою. 
Не поможет. Только если на другой форум.
Нет, но и не надо!
Тут мне понятно что ТС просто очень многого не понимает.. я умею слушать людей, которые не понимают или понимают ограниченно но в пределах своих знаний/возможностей, иногда это даже полезно, чистый незамутненный готовыми решениями взгляд.
p.s. или очередной троллинг, очень грустно
Тут мне понятно что ТС просто очень многого не понимает.. я умею слушать людей, которые не понимают или понимают ограниченно но в пределах своих знаний/возможностей, иногда это даже полезно, чистый незамутненный готовыми решениями взгляд.
p.s. или очередной троллинг, очень грустно
rPman, бегите из этого треда. Я вас прикрою.
просто скажите понятно вам или нет.
Нет
2 Wi-Fu:
что и требовалось доказать. Значит Вы не можете объяснить, значит у Вас нет кристалльной ясности.
Тут мне понятно что ТС просто очень многого не понимает..
2 rPman:
Это называется: "вы тут кругом все дураки, я не могу объяснить почему дураками считаю вас, но себя точно считаю гасконцем".
Нет, но и не надо!
Тут мне понятно что ТС просто очень многого не понимает.. я умею слушать людей, которые не понимают или понимают ограниченно но в пределах своих знаний/возможностей, иногда это даже полезно, чистый незамутненный готовыми решениями взгляд.
p.s. или очередной троллинг, очень грустно
Тут мне понятно что ТС просто очень многого не понимает.. я умею слушать людей, которые не понимают или понимают ограниченно но в пределах своих знаний/возможностей, иногда это даже полезно, чистый незамутненный готовыми решениями взгляд.
p.s. или очередной троллинг, очень грустно
Скорость это самая маленькая проблема на сегодняшний момент. Куда важнее размер:
https://bitcointalksearch.org/topic/ultimate-blockchain-compression-w-trust-free-lite-nodes-88208
https://bitcointalksearch.org/topic/ultimate-blockchain-compression-w-trust-free-lite-nodes-88208
О хранении и шла речь в самом начале... глупости в названии топика и в сообщени я просто опустил за ненадобностью
Я не изучал leveldb но многие key-value базы данных спокойно горизонтально масштабируются, ничто не мешает вместо оной базы вести две/много... одна для данных, к которым очень частый доступ (можно статистически выявить такой интервалл времени, в пределах которого чаще всего происходит доступ к монетам) и другая для старых данных, к которым доступ сравнительно редок. ВСЕ... работы не много польза - на порядок.
p.s. я не хочу больше вести беседу в этом треде, вы тут на друг друга откровенно наезжаете, это уже смахивает на очередной троллинг
Я не изучал leveldb но многие key-value базы данных спокойно горизонтально масштабируются, ничто не мешает вместо оной базы вести две/много... одна для данных, к которым очень частый доступ (можно статистически выявить такой интервалл времени, в пределах которого чаще всего происходит доступ к монетам) и другая для старых данных, к которым доступ сравнительно редок. ВСЕ... работы не много польза - на порядок.
p.s. я не хочу больше вести беседу в этом треде, вы тут на друг друга откровенно наезжаете, это уже смахивает на очередной троллинг
Какое все это имеет отношение к
Ссылаются друг на друга не только блоки, но и транзакции. Можно разобрать блоки на транзакции, а потом сгруппировать транзакции по-другому.
При проверках нужно уметь находить в первую очередь исходные транзакции и только потом - блоки, к которым транзакции относятся.
Учитывая, что заголовки блоков имеют фиксированный размер, то искать сами блоки можно просто индексированием (умножением порядкового номера блока на его размер).
Если предположить, что цепочка верифицируется перед сохранением, то достаточно будет найти исходные транзакции (и не нужно будет пересчитывать контрольные суммы блоков, т.е. собирать все нужные транзакции для этого из разных мест)
по данному критерию
Вы не написали, по какому "данному" критерию. Учитесь мысли внятно излагать, для начала.
Биткоин цепочка состоит из блоков, блоки из транзакций, транзакции из входов и выходов, всё это - элементы (цепочки). Элементы являются данными, естественно.
Элементы можно при записи физически переупорядочивать.
Нет там ошибок, потому что Wi-Fu не может объяснить, в чем ошибки заключаются.
Он тупо выпендривается и не способен объясняться (т.е. доходчиво выражать мысли словами).
Элементы можно при записи физически переупорядочивать.
ну может быть единственное, о чем можно было бы просто ... указать на ошибку.
Нет там ошибок, потому что Wi-Fu не может объяснить, в чем ошибки заключаются.
Он тупо выпендривается и не способен объясняться (т.е. доходчиво выражать мысли словами).
Вопрос оптимизации доступа в БД - это вопрос хранения данных. Когда проблема даст о себе знать - будьте уверены, разработчики введут ряд ассоциативных таблиц с "продуманной индексацией" - и этого будет более чем достаточно. Но ТС пишет не об этом. Да, возможно он хотел это сказать, но кашу, которую он вывалил в 1м сообщении, надо разбирать тщательно.
Не путаем, индексы это копия данных в особой форме/структуре, а идея ТС относится к частному случаю реализации хранения... в терминах классических баз данных - это кластер.Сюрприз, бывают что индексы создаются только на одной таблице кластера - горячей, а на других, к примеру, на архивных, индексы не создаются.
Между прочим отличная идея, к моменту, когда для работы кошелька скорости обычного устройства чтения будет не хватать, даже тупое разделение старые транзакции на HDD - новые транзакции на SSD позволит ускорить обработку блоков (особенно это актуально майнерам и пулам, так как вероятность словить орфан напрямую зависит от скорости обработки блока, секунда - незаметна, шесть секунд - +1% к orphan, минута - уже +10% к вероятности словить orphan)..
p.s. но пока этого точно не требуется
и к этой идее нужно будет вернуться, когда в одном блоке будет типичным размещать сотни тысяч транзакций.
p.s. но пока этого точно не требуется
и к этой идее нужно будет вернуться, когда в одном блоке будет типичным размещать сотни тысяч транзакций. У меня одного возникло ощущение что ТС потерялся между моделью ("блок-цепь") и ее реализацией ?
Да, тебе удалось ухватить идею самым краем мозга.
Я как раз предлагаю подобрать такую реализацию, которая бы ускоряла работу с моделью.
Можно попробовать перетасовать данные в биткоин-цепочке для того, чтобы ускорить доступ к ним.
Т.е. сначала разделить все сущности биткоин цепочки на ER-диаграмме,
потом выделить транзакции и входы-выходы.
Транзакции будут образовывать граф, состоящий из узлов (кошельки?) и ребер (собственно вход, транзакция, выход).
Предлагается подумать, какой алгоритм (хеш по группам номеров счетов?) позволит сгруппировать транзакции таким образом,
чтобы транзакции смежные в графе находились физически рядом в хранилище данных.
Такая локальность данных позволила бы быстрее считывать транзакции для целей верификации.
Некоторые сейчас напишут, что у них и так всё быстро работает.
Если этот ваш биткоин такой удобный, то почему тогда кошельки ещё не на каждом мобильном девайсе?
Т.е. сначала разделить все сущности биткоин цепочки на ER-диаграмме,
потом выделить транзакции и входы-выходы.
Транзакции будут образовывать граф, состоящий из узлов (кошельки?) и ребер (собственно вход, транзакция, выход).
Предлагается подумать, какой алгоритм (хеш по группам номеров счетов?) позволит сгруппировать транзакции таким образом,
чтобы транзакции смежные в графе находились физически рядом в хранилище данных.
Такая локальность данных позволила бы быстрее считывать транзакции для целей верификации.
Некоторые сейчас напишут, что у них и так всё быстро работает.
Если этот ваш биткоин такой удобный, то почему тогда кошельки ещё не на каждом мобильном девайсе?
Jump to: