由词典程序自动完成，训练过程很快。
这个得研究一下，之前没有接触过这种压缩方式，我只对词典内容压缩，词条本身不压缩，貌似这种方法是很难取得比较好的效果，除非是直接用sqlite的压缩插件进行全库压缩 
1 个赞
我之前做过一个全文检索的测试
5万词条
不压缩：用时 394.9792 ms
压缩：用时1410.0532 ms
当然如果加上多线程的话，压缩方式下的检索速度还可以再提高。
2 个赞
1G以上确实是会比较耗时，所以我的想法是这种实时刷新的只用于新格式，如果是MDX，就在IDE里面批量修改后再一次转换
如果是协同的话，我就建议建一个在线文档平台，用MySQL做为后台数据库会比较好！
1 个赞
我好像没太懂这是啥意思，词条内容只需要存储一遍的。SQLite 全库压缩其实有一个插件也是用的 zstd 哈哈。总之 zstd 就是可以分析出你想要压缩的很多小文档的共同特征，存到一个字典里面，然后用此字典来压缩和解压，可以取得和 mdx 的块压缩策略相近的压缩结果。
这个用时的含义是什么？
楼主加油！
MediaWiki 就挺好的哈哈，不过技术不是关键，主要是人力。
哦哦，那我明白，这种方法很好
我的意思是，我是直接把词典内容压缩后话到数据库的字段里，单词字段本身不压缩
就是用了多长时间
1 个赞
这个策略是我和你是一样的。
我是说是查询一个词组的时间吗，还是其他意思。
1 个赞
是的，就是用一个词组做一次全文检索所用的时间
1 个赞
其实我还想到一个办法来提高速度，就是把词典内容里的最大编码和最小编码放到另外两个字段里，全文检索的时候，先计算出要搜索的内容的最大编码和最小编码，如果要搜索的内容的最大编码和最小编码不在词典内容的最大和最小编码范围内，就直接跳过，这样应该可以节省解压缩的时间和减少数据返回。
但这个没有试过，不知实际效果如何。而且很多时候词典内容都带有HTML标记(不是Compat的情况)，这样子意义就不大。
我主要有两个顾虑：
1）生成索引可能会让数据库文件变得很大
2）那个sqlite的全文检索功能估计在压缩模式下用不了。
不会很大，我上面提到过，全文索引的体积是 mdx 的 1.25 倍左右，不同 mdx 有不同数据。
SQLite 全文索引可以只存储索引，不存储数据。即索引只是引导搜索到数据表的 id，仅此而已，你的数据表该压缩就压缩。
当然了，时间换空间似乎也是一种解决方法，但是现在存储空间也不是很贵。
3 个赞
所以对于家里有矿的来说，可以直接选择不压缩 
期待即时编辑功能！如果再集成即时修改css和js就更好了。
这个时代，人们对时间比空间要敏感得多，稍等一会儿就不耐烦。
何况词典的文字部分一般不会太大，大部分只是几兆而已，像《汉语大词典》这样的大部头不压缩也不过一百多兆。
ZSTD果然厉害 ，我做了一个测试, 结果如下：
源MDX: 511MB (keyblock数量: 1047, recordblock数量: 44513)
======================================
ZSTD (词典模式，随机训练20个样本，压缩级别5)
压缩后大小:968MB
用时： 3分钟
======================================
LZ4 （压缩级别12）
压缩后大小:1.47GB
用时： 4分钟
实际时间可能更短，因为我在生成sqlite文件后还会更新一些排序和其它方面的统计信息
1 个赞
是的，其实压缩最多的场景可能就维基类或者是例句库之类的词典
1 个赞
压缩级别可以调到 19 ，zstd 是压缩慢，解压快的，样本也可以多训练一些，训练过程也是很快的，另外它的字典大小，你可以调优一下，越大的词典，词典能被压缩越小，当然有一个限度。我调优之后 zstd 压缩能比 mdx 大 10%-20%，当然，这并不适用于所有词典。
2 个赞
但我还有一个疑问，比如说已经生成内容，以后再单独添加或者更改记录的时候，怎么在已有的训练好的词典上再进行训练呢？
据我所知是不行的，只能全部改。
不过修改的记录不多的时候，是不是训练新的词典也不会有太大的提升？
1 个赞