full_test: как суммировать размер БД?

Для Virtuoso лучше каждый раз сбрасывать и использовать указанный файл конфигурации (необходимо зарезервировать временные журналы).

Процесс загрузки сначала импортирует содержимое, удовлетворяющее памяти, или выполняет несколько раундов поиска, но не выводит результаты, чтобы избежать чтения с диска в начале запроса. vstree напрямую загружает всю память?

Сначала завершить объединение тестов, затем измерить lubm500M и bsbm500M — 90 серверов. jemalloc?

В сравнительной таблице различных версий следует добавить столбец со средним геометрическим значением. В реальности большинство запросов являются простыми запросами, и было бы хорошо иметь ещё одно среднее значение, соответствующее нормализации данных и их суммированию. Результаты DBpedia q6 теперь должны быть статистически сопоставлены и сравнены, включены в результаты тестирования.

После улучшения kvstore процесс сборки значительно ускорился, теперь создание vstree стало узким местом. В preFilter необходимо учитывать не только предикат, но и размер таблицы, а также степень, некоторые узлы лучше фильтровать!

Разрешить одновременное использование нескольких баз данных, указывать базу данных при запросе, это позволит поддерживать from, но каждая база данных будет независимой; добавить Scala API; управлять разработкой с помощью Git;

создавать B+ деревья и деревья vstree снизу вверх; ускорить операции обновления, такие как insert и delete, рассмотреть возможность добавления модификации исходной операции; при удалении данных полностью удалить данные может вызвать серьёзные проблемы, сохранить пустое дерево? Или рассмотреть случай пустого дерева при вставке?

Если объём обновлений слишком велик, можно сразу перестроить индекс, небольшие обновления можно записать на страницу переполнения, объединить во время простоя системы; например, вести учёт операций вставки и удаления, каждый раз проверять несколько, определять отношения; один и тот же триплет в одном индексе может появляться не более одного раза: если он уже существует, вставить его следует отменить? Если его ещё нет, удаление следует отменить?

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

Использовать машинное обучение для оценки функций? Изучать параметры? Изучать модель? Но машинное обучение не имеет чёткой границы для новых задач, в отличие от математической оценки функций, которая может гарантировать верхнюю границу для любых условий (в настоящее время в базе данных мало кто использует машинное обучение для оценки). URI уникален, в RDF-графике нет одинаковых узлов меток, невозможно объединить похожие узлы, нельзя использовать самоидентичные предварительные обработки для ускорения запросов. DBpedia содержит самые последние данные, старые относительно малы. Оптимизация функции count: достаточно глубокого поиска, без создания промежуточных таблиц. Добавить индексы внутри каждого узла B+ дерева, разделить ключи? Можно ли рассматривать литералы как узлы vstree, ускорить фильтрацию? При объединении могут возникнуть большие накладные расходы, и можно рассмотреть возможность использования соседних рёбер для фильтрации литералов... Но длина цепочки sp2o должна быть небольшой?

Буфер объединения: использовать массив вместо карты, идентификатор может находиться в нескольких столбцах, id2string может содержать ошибки (разные префиксы, разные списки)! Используйте Bstr[2^16], только для сущностей, также в качестве буферов (после пересечения с кандидатами), если в диапазоне идентификаторов, используйте, иначе создайте (не обновляйте?) (при объединении с hulin обсудите, существует ли). Метод: просканируйте все связующие точки слева направо, чтобы найти узел без литералов (если нет?), и сохраните его для этого столбца. Просканируйте столбец и получите максимальный и минимальный идентификаторы, установите минимальный идентификатор в качестве смещения и постройте только массив максимального идентификатора и минимального идентификатора. (чем меньше интервал, тем лучше, как насчёт использования хеш-конфликтного списка здесь) Установите разный размер буфера для разных деревьев в сборке/запросе, например, sp2o и op2s с 16G, p2so с 16G. Установите string2id и id2string на 1–2G. Во время тестирования также лучше подсчитать самый длинный string и общий размер строк.

Fangzhen Zhihui: используйте gStore в качестве фоновой базы данных, определите схему, такую как область, модель и т.д. Проблема эффективности удаления рекурсивно, например, удаление всей модели (без отношений, быстрее, чем удаление целой таблицы). Рассмотрите возможность добавления ограничения домена, основываясь на этом ребре, удалите всё. Домен можно выразить с помощью префикса таблицы, но x может принадлежать нескольким доменам. Объединить большие объёмы вставок и модификаций. Необходимо поддерживать модификацию предикатов, не возникнет ситуации pp o. Лучше добавить предикаты сравнения. Удалить предикаты классов, тогда все экземпляры с этим предикатом также должны быть удалены. Модель/область: каждому объекту принадлежит один идентификатор области? Только классам присваивается идентификатор? Только самым верхним классам присваивается идентификатор?(это усложняет запрос, снижает эффективность). Разделите несколько баз данных, рассмотрите шаблоны, если домены и домены не пересекаются. Если домены не полностью независимы, их нельзя напрямую разделить на несколько баз данных! Если разделение требует рассмотрения соединений, после разделения его можно непосредственно использовать для распределённых баз данных.

bsbm300M q8.sql — новый gStore хуже. Это потому, что этот запрос линейный, что означает, что порядок соединения dfs не оптимизирован, и время, затраченное на preFilter, возможно, не изменится. Может быть, использовать не-dfs порядок для объединения? Нам нужно сравнить время каждой части в q8.sql.

Использовать vf2 для сравнения? Позаимствовать его идею? Однако vf2 делает стандартное поддерево изоморфизма, а не поддерево включения, необходимо изменить. vf2 и gStore взаимно заимствуют, другой способ фильтрации? Объективно говоря, многоугольник vstree по-прежнему является лучшим.

Заблокировать B+ дерево, можно напрямую обновить ранг узла, сделать его ранг максимальным (самый высокий бит или второй по величине), разблокировать и очистить соответствующий бит. (Однако это вызовет значительные накладные расходы, поскольку изменение памяти кучи является относительно длительным процессом, требующим линейного времени поиска). На самом деле B+ дерево должно сосредоточиться на производительности чтения, а не на балансе чтения и записи, например, не использовать блочную структуру, напрямую сохранять узел как блок. Также можно сделать каждый узел фиксированного размера, упорядочить хранение, все значения сохраняются в виде записей файлов, только добавляются, но не удаляются. Процесс запроса почти не изменяет кучу, почти не требует освобождения блоков, можно напрямую сохранить номер свободного блока и текущий максимальный номер блока, вместо того, чтобы хранить все блоки в использовании. Также из-за этой причины дерево почти не модифицируется в процессе запроса, избегая дорогостоящих операций поиска указателя кучи. Исправить: необходимо вернуть результат предиката запроса, сначала нужно знать, какие предикаты находятся в select, для этого требуется сканирование запроса.

Изменить на BestJoin, используя индексные списки и суперрёбра: накладные расходы на объединение будут сокращены, поэтому мы можем кэшировать больше для запросов! Определите разный размер кэша для сборки и запроса в makefile с -D. Как насчёт BFS вместо DFS? Требуется общий параллельный модуль: Параллельные потоки должны соответствовать количеству потоков процессора, не слишком много. Три уровня детализации, несколько запросов sparql параллельно, один sparql с несколькими базовыми запросами параллельно, одна базовая очередь запросов, параллельная потоковая передача двух таблиц, когда они объединены, необходимо добавить блокировку (запретить выход). Блокировка влияет на kvstore во время параллельной работы (vstree в основном полностью находится в памяти, поэтому нет большого влияния), проблема замены, требуется блокировка (запрет на замену). Протокол блокировки дерева? Много запросов параллельно, объединение памяти может превысить лимит, необходимо выбросить исключение при сбое выделения вектора, перехватить исключение в другом месте (например, дождаться свободной памяти).

Следите за обновлением Jena и устраняйте ли они ошибки. Время и улучшение каждого модуля. Таблица производительности gStore, сравнение до и после. Чтобы поддерживать 10 миллиардов на одной машине, память должна превышать 100G. Измените длину Bstr на длинный длинный тип. (Также обновите везде, где это связано с длиной или strlen, например Signature::encodeStr2Entity). Измените тип идентификатора сущности/литерала на беззнаковый. +++++++++++++++++++++ Создайте новый модуль управления идентификаторами, который должен быть эффективным и стабильным, поместите его в Util. Используется в storage, Database, VStree и других местах. Лучше переместить StringIndex в KVstore. В модульном тесте вставка/удаление должны быть протестированы для повышения покрытия!!! Слишком много объектов для lubm500M, поэтому это очень медленно. Текст запроса:

Узлы содержат только смещение файла Bstr, используя тип long long. Можно рассмотреть использование инвертированного индекса для id2string напрямую, без использования B+ дерева (поскольку вставки и удаления происходят редко). Но string2id вызывает затруднения и не может быть реализован напрямую с помощью инвертированного списка.

Get не может вернуть все уникальные значения, так как вставки и удаления также требуют вызова get. За исключением модуля join, остальные модули, связанные только с запросами, также лучше сделать уникальными.

Watdiv5000 завершается неожиданно — p2so индекс: 541740149 549240150 entity 26060745 literal 23964574 pre 86

Оптимизация объединения и удаления элементов для повышения эффективности. В настоящее время проблема заключается в small_aa small_ab q3.sql. Для объединения и удаления необходимо улучшить производительность.

Сокращение индексов, таких как p2s и p2o, можно заменить на p2so. Аналогично, s2po и o2ps также могут быть использованы. Кроме того, sp2o обычно больше, и его можно использовать с s2po для поиска по бинарному дереву. В итоге потребуется всего 6 + 3 деревьев kv. (Существует множество проблем, реализация s2o требует сортировки, что может привести к высокой стоимости.) (Можно рассмотреть совместное использование s2-индекса, сохраняя o и po в качестве значения, где один ключ соответствует двум Bstr.)

Реализация so2p с использованием s2p и o2p может вызвать ошибку. S P O1 S2 P O

Требуется тестирование на реальных данных приложений. Когда случай имеет вид ?s p1 o ?o p2 o, это будет рассматриваться как два основных запроса и отвечать отдельно. Это хорошо? Или если рассматривать как один BGP, как мы можем выполнить 2-хоповое кодирование?

Проблемы с join (preFilter на основе количества p) и stream (оценка ошибок или утечки памяти). Вместо возврата num из b-дерева следует использовать существующую реализацию (следует ли это делать на уровне реализации и как обеспечить эффективность?). В Query создать соответствующие пары p2num и sp2num, чтобы избежать повторного поиска. (Следует ли разделять o2p, o2ps и o2s на entity/literal для ускорения? Следует ли использовать инвертированный список для id2string?)

Рассмотреть возможность использования встроенного ассемблера для оптимизации в больших циклах (провести сравнительное тестирование для оценки эффективности). Лучше полностью разделить entity и literal.

Join::preFilter — в некоторых случаях предварительная фильтрация, в других случаях последующая фильтрация в зависимости от количества результатов и производительности фильтрации границ. Не должно вызывать ошибок. При использовании allFilterByPres не всегда хорошо, иногда слишком дорого! (dbpedia2014, self6.sql) Использовать «хорошо спроектированный» в GeneralEvaluation, чтобы не выбирать все выбранные запросы; три узких места: getFinalResult, copyToResult и allPreFilter. Эффективность join_basic крайне важна и является ключевой.

Другой способ фильтрации: использовать sp2num для оценки количества или также оценить количество результатов vstree, установить тройное соединение (чтобы избежать повторной обработки в будущем). Можно рассмотреть добавление литералов только при объединении (необходимо учитывать ограничения констант, рассматривать entity и literal отдельно), максимум добавить один заранее, чтобы гарантировать запуск join. При поиске критических точек entity и literal в idlist обратите внимание на левый маленький и правый большой, не сканируйте просто. Будет ли окончательная проверка ограничений спутниковых границ более эффективной? (Спутниковые границы всегда однонаправленные.) Нет необходимости объединять entity и literal вместе, кроме того, порядок объединения может быть очень важен. (Каждый раз следует выбирать наименьшие два или несколько форм слияния.)

+++++++++++++++++++++ Путь с метками, а не способ фильтрации и проверки. Анализ структуры cas и шаблонов запросов. Преобразование ask в оценку троек констант.

Статистическая информация о размере базы данных: использование du -h или ls -lR вызывает проблемы, но обычно разница не слишком велика. Проблема с памятью в gStore: с одной стороны, возможно, некоторые блоки не заполнены, с другой стороны, возможно, предварительно выделено слишком много блоков.

Тесты:

• Подпись в двоичном файле db не удаляется в программе, но должна быть удалена для экономии места.

• Единичные тесты:

  • http://www.cnblogs.com/linux-sir/archive/2012/08/25/2654557.html
  • http://www.ibm.com/developerworks/cn/linux/l-cn-cppunittest/
  • https://my.oschina.net/vaero/blog/214893

• Watdiv5000 выдаёт ошибку при создании индекса p2? (индекс p2so слишком велик?)

• Jena, похоже, имеет проблемы с ответами на запросы lubm5000, например, q0.sql.

Если длина кодирования подписи увеличивается с 800 до 1200 + 1000, время сборки значительно увеличивается, а время запроса немного уменьшается или остаётся неизменным. Для q6.txt в DBpedia последнее время подписи составляет 16366841 мс, а размер такой же, как и исходный, 457393467 (но размер q6.sql в jena равен 17852675, какой из них правильный?).

Следует ли создать систему журналов для облегчения отладки? Как откатиться при возникновении ошибки, непосредственно управляя версиями? (Делать ли резервную копию исходного индекса перед каждой операцией вставки/удаления?)

Во время тестирования каждого запроса, помимо времени, следует также записывать количество результатов для последующего использования. Необходимо провести полное тестирование dbpedia перед фиксацией!!! (Просто проверьте размер ответа на запрос).

DBpedia q0.sql работает медленнее в gstore, поскольку фильтрация занимает много времени, и набор кандидатов большой, после чего необходимо многократно проверять. bsbm10000 self3.sql — pre_filter слишком дорогой. 3204145 для ?v0 1 для ?v1 всего 3204145. Возможно, нам следует начать с ?v1 или использовать p2s или p2o (возможно, сначала p2so, затем pre_filter, затем генерацию). self5.sql также имеет слишком большую продолжительность preFilter. Можно рассмотреть возможность фильтрации в зависимости от ситуации или исследовать причины высоких затрат. Возможно, фильтрацию можно не проводить, или можно изменить условия фильтрации, или фильтровать только граничные ограничения одноточечных вершин.

Virtuoso: dbpedia2014 — этот тест выполняется медленно и часто возникают проблемы. Лучше выполнять по одному столбцу за раз. 100441525 мс для загрузки и размер 17672699904/1000–39846 КБ. 50 мс для q0.sql 217 мс для q1.sql 210 мс для q2.sql 23797 мс для q3.sql 5536 мс для q4.sql 2736 мс для q5.sql 9515231 мс для q9.sql

Virtuoso: bsbm_10000 — 40137 мс на загрузку, размер 635437056/1000–39846 КБ.

Использование multi-join и stream по сравнению с jena: gstore работает хуже, чем jena в следующих случаях:

• Серия bsbm: self1.sql, sellf3.sql, self8.sql (self4,5,6).
• Серия dbpedia: q3.sql, q4.sql, q5.sql (q9.sql).
• Серия lubm: q0.sql, q2.sql, q13.sql, q16.sql.
• Серия watdiv: C1.sql, F3.sql.

Производительность vstree оказывает большое влияние на процесс объединения из-за размера набора кандидатов. Время сборки составляет 3 порядка... Кажется, оно не связано напрямую с длиной подписи (поэтому мы можем увеличить её для лучшей длины!).

BSBM: когда запрос содержит "^^" (self0.sql), gstore ничего не выводит. А когда результаты содержат "^^" (self3.sql, self8.sql), gstore опускает то, что связано с "^^". (Это приводит к несоответствию, потому что другие три СУБД поддерживают этот символ. Virtuoso, однако, может работать с запросами, содержащими "^^", но не будет выводить "^^..." в результатах).

sesame не поддерживает lubm (недействительный IRI), и... Невозможно работать с такими большими наборами данных, как dbpedia2014, watdiv_300M, bsbm_100000...

DEBUG

Ошибка при использовании запроса «....» > ans.txt в gconsole.

lubm5000 q1 q2 delete/insert/query 1003243 none после vstree

dbpedia q6.sql

Ошибка сборки БД, если количество троек больше 500М.

ЛУЧШЕ

Добавить слой доступа к данным, схему данных и исходный код для генерации доступа к данным.

В функции encodeBasicQuery в BasicQuery.cpp обнаружено, что pre_id == -1, можно сразу остановить запрос и вернуть пустое значение!

Заменить операцию поиска Node* в модуле KVstore на treap (или использовать указатели, чтобы избежать поиска?).

Не удаётся выполнить запрос предикатов, поскольку в VSTREE можно фильтровать только точки, а не рёбра (если есть возможность разделить и рассмотреть отдельно). (Или интегрировать в vstree, добавить 01/10 в начале для разделения s/o и p. однако результат равен 11 после OR, предикаты не так многочисленны, поэтому если перейти в ветку s/o, это будет слишком дорого. А как насчёт кодирования информации?)

ДОКУМЕНТЫ:

Как насчёт STL:

http://www.zhihu.com/question/38225973?sort=created http://www.zhihu.com/question/20201972 http://www.oschina.net/question/188977_58777

ПРЕДУПРЕЖДЕНИЕ

Нельзя допускать переопределения проблем, они уже решены (иначе это повлияет на использование других библиотек, vim quickfix будет постоянно отображаться) (потому что это конфликтует с QueryTree, в конечном итоге отложено) Также следует обратить внимание на проблемы несоответствия типов (проблема с многобайтовыми константами в SparqlLexer.c) Переменные определены, но не используются (можно не учитывать для анализа, генерируемого antlr3, потому что файл большой, автоматически генерируется, влияние невелико) В будущем лучше использовать последнюю версию antlr, поддерживающую C++, для повторного создания, основанную на объектно-ориентированном подходе, чтобы предотвратить конфликты с определениями в библиотеках Linux! (в настоящее время перед переопределением добавляется префикс)

СОХРАНИТЬ

Необходимо максимально оптимизировать большое количество циклов внутри!

— gStore также использует гомоморфизм подграфов!

— Всегда используйте valgrind для тестирования и улучшения.

— Эта версия предназначена для разработки, в конце концов необходимо перенести весь проект в репозиторий gStore для публикации. При переносе сначала удалите все файлы из gStore, кроме .git и LICENSE, затем скопируйте (не копируйте LICENSE, потому что версии разные; также не копируйте NOTES.md, потому что он используется только для записи вопросов разработки).

— Создайте git-страницу для gStore.

— При тестировании всё должно быть в режиме горячего запуска, чтобы иметь смысл! gStore должен быть скомпилирован с -O2 оптимизацией, и все отладочные макросы должны быть закомментированы.

— Новый алгоритм занимает слишком много времени при холодном запуске, даже если это всего лишь накладные расходы на 0 раундов join, он всё равно велик, для сравнения используется горячий запуск.

— Если переменная не появляется в запросе в графе, следует ли возвращать пустое значение или считать запрос недействительным?

СОВЕТЫ

Рассмотреть возможность использования hdfs или hbase, тогда можно будет использовать существующие базы данных компаний, но не будет ли это конфликтовать с существующим внешним и внутренним обменом?

Запросы числовых типов с действительными областями [-bound, bound] трудно сопоставить, нужно ли их кодировать отдельно? В наборе данных не должно быть диапазонов. Запрос должен быть закодирован и проверен после фильтрации.

x>a, x<b, >=, <=, a<x<b, x=c vstree сталкивается с "1237"^^<...integer>, не следует брать строку напрямую, а преобразовывать её в число и кодировать. Сложные моменты: преобразование ограничений в дизъюнктивные нормальные формы, ограничения для одной и той же переменной, ограничения между различными переменными.

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

Создать документ, пересмотреть gStore: метод соединения, способ кодирования, план запроса.

Прочитать и проанализировать исходный код PG.

Обеспечить правильность и эффективность модульного тестирования, проанализировать производительность и утечки памяти с помощью valgrind, повторить более глубокие оптимизации (даже на уровне сборки), чем больше повторений, тем больше следует углубляться в оптимизацию.

Можно попробовать watdiv_1000/watdiv_2000/watdiv_1000M/freebase/bio2rdf.

Стратегия ограниченной глубины рекурсивного кодирования: построение с использованием топологического упорядочения, как насчёт обновлений? (добавление соседних вершин кодировок) (эффективность и корректность?).

Текущая реализация vstree основана на B+ дереве, на самом деле нет необходимости хранить один и тот же узел дважды. Можно поместить дочерний узел в родительский узел, поместить entry в массив родительского узла или выделить корневой узел отдельно.

(для этого нужно думать сверху вниз).

Структура vs*tree в статье на самом деле более сложная, между узлами существует множество связей, каждый уровень выполняет сопоставление подграфа, эффект фильтрации должен быть лучше, впоследствии стоимость соединения join, вероятно, будет меньше. Текущая реализация vstree проще, она фильтрует только один узел-кандидат за раз, а затем объединяет их вместе, но эффект не очень хороший.

При рассмотрении всех случаев в index_join, однократного соединения нескольких сторон, пересечения/фильтрации и т. д., multi_join не меняется.

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

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

Время и объём памяти vstree велики, при тестировании gstore следует распечатать/проанализировать время каждой части. Распечатка экземпляров кодирования используется для анализа и тестирования, как разделить или вычислить пространство (исключительно по направлению, а не по длине).

Первая строка в full_test — это информация о переменных (следует ли сравнивать с jena, когда используется select *).

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

Автоключевые слова и интеллектуальные указатели?

Реализовать пул памяти для управления памятью?

Соединение может быть не в порядке дерева, рассмотреть оценку стоимости каждого соединения двух таблиц.

1. Использовать машинное обучение (классификация запросов, градиентный спуск, настройка параметров) для оценки порядка глубокого поиска.
2. Сжатие строк: глобальный контроль того, запускать ли (например, во время установки), одновременно/по-разному для памяти и диска. Следует ли сжимать строки на основе структуры (один флаг)? Сопоставление ключевых слов? Основные операции со строками — сравнение, соответствующие алгоритмы сжатия должны быть эффективными и не слишком сложными!
3. Реализация запросов к предикатам (ещё раз посмотреть статью).
4. Добавьте переменные в запрос, иначе соединение может быть невозможно, или это может повлиять на эффективность соединения. Например, A->c, B->c, изначально это должно быть через c, соединённое подграфом, но текущая реализация gstore не может распознать.

Рассмотрите возможность параллельной оптимизации: можно ли распараллелить процесс загрузки? vstree может выполнять фильтрацию параллельно, также можно использовать конвейерную стратегию при соединении, передавая полученный результат следующей операции.

Четко указать вклад каждого человека.

SSD

Как установить права чтения/записи/исполнения для всех пользователей /home/ssd? mkfs.ext4 -E stride=128,stripe-width=128 /dev/sdb tune2fs -O ^has_journal /dev/sdb Измените /etc/fstab: /dev/sdb /home/ssd ext4 noatime,commit=600,errors=remount-ro 0 1 Чтобы проверить правильность: mount /home/ssd Убедитесь, что планировщик ввода-вывода является noop (только ssd) или deadline (ssd + диск), иначе: Добавьте в rc.local: echo deadline(noop,cfq) >(>>) /sys/block/sdb/queue/scheduler (откройте обрезку, если ssd и система разрешена)

Рассмотрите поддержку GPU (может быть расширенной функцией корпоративного издания).

RAID

Изучите способ Orient DB, который может поддерживать режим без схемы, полный режим и смешанный режим.

ACID? neo4j GraphDB

Отдельный файл gStore? Встраиваемый, лёгкий, удобный для переноса, сделать его библиотекой для вызова Python и т.д.

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

mysql подходит для хранения атрибутов, gstore подходит для обработки отношений, trinity подходит для алгоритмов. Может ли gstore обрабатывать различные требования к графическим алгоритмам, например, находить кратчайший путь между двумя точками? Например, регулярные пути запросов?

Нет необходимости закрывать синхронизацию буфера ввода-вывода, потому что в основном используется ввод-вывод C.

Можно ли рассмотреть возможность использования алгоритма VF2 для выполнения сопоставления подграфов? Более эффективно, объединить их? Рассмотрим разделение по частоте глаголов

Например, можно создать два SP-дерева, и размер кэша для них должен быть разным.

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

Рассмотрите возможность использования Bloom Filter и FM-sketches.

DataSet

http://www.hprd.org/download/

Использование GIT

http://www.ruanyifeng.com/blog/2014/06/git_remote.html https://git-scm.com/book/zh/v1/%E8%B5%B7%E6%AD%A5-%E5%88%9D%E6%AC%A1%E8%BF%90%E8%A1%8C-Git-%E5%89%8D%E7%9A%84%E9%85%8D%E7%BD%AE

Чтобы увидеть все операции в Git, используйте git reflog.

Как зафиксировать сообщение

package.json http://www.json.cn/ https://www.oschina.net/news/69705/git-commit-message-and-changelog-guide https://sanwen8.cn/p/44eCof7.html

1. Фиксируйте изменения по одному, каждый коммит должен делать только одно действие.

2. Между заголовком, телом и нижним колонтитулом должна быть пустая строка.

3. Первая буква заголовка должна быть заглавной, заголовок не должен быть слишком длинным, это должно быть краткое описание сути изменений.

FIX: ... ADD:... REF:... 代码重构 SUB:...

4. Каждая строка не должна быть слишком длинной. В нижнем колонтитуле укажите своё настоящее имя и опишите влияние изменений (возможно, изменение структуры кода).