不要太急，现在只是一个很初步的功能，还要花长时间完善
1 Like
大小区别还是挺明显的，zstd 压缩明显小一些，然后就是 zstd 的代码要复杂一些，因为要达到最好压缩效果就要自己训练词典（其实就是选择一些文档来生成一个字典）。
1 Like
这个训练的过程得最终用户自己来完成？
由词典程序自动完成，训练过程很快。
这个得研究一下，之前没有接触过这种压缩方式，我只对词典内容压缩，词条本身不压缩，貌似这种方法是很难取得比较好的效果，除非是直接用sqlite的压缩插件进行全库压缩 
1 Like
我之前做过一个全文检索的测试
5万词条
不压缩：用时 394.9792 ms
压缩：用时1410.0532 ms
当然如果加上多线程的话，压缩方式下的检索速度还可以再提高。
2 Likes
我只是提想法啦！10条里有1条能有个有用的信息，我就知足了！ 
多线程、极限优化（瓶颈在IO还是CPU还是UI等）当然更好了，但都是供你参考
- 选
- 当下选
- 当下弃，日后适时再择。
- 弃
1G以上确实是会比较耗时，所以我的想法是这种实时刷新的只用于新格式，如果是MDX，就在IDE里面批量修改后再一次转换
如果是协同的话，我就建议建一个在线文档平台，用MySQL做为后台数据库会比较好！
1 Like
我好像没太懂这是啥意思，词条内容只需要存储一遍的。SQLite 全库压缩其实有一个插件也是用的 zstd 哈哈。总之 zstd 就是可以分析出你想要压缩的很多小文档的共同特征，存到一个字典里面，然后用此字典来压缩和解压，可以取得和 mdx 的块压缩策略相近的压缩结果。
这个用时的含义是什么？
楼主加油！
MediaWiki 就挺好的哈哈，不过技术不是关键，主要是人力。
哦哦，那我明白，这种方法很好
我的意思是，我是直接把词典内容压缩后话到数据库的字段里，单词字段本身不压缩
就是用了多长时间
这个策略是我和你是一样的。
我是说是查询一个词组的时间吗，还是其他意思。
1 Like
是的，就是用一个词组做一次全文检索所用的时间
1 Like
其实我还想到一个办法来提高速度，就是把词典内容里的最大编码和最小编码放到另外两个字段里，全文检索的时候，先计算出要搜索的内容的最大编码和最小编码，如果要搜索的内容的最大编码和最小编码不在词典内容的最大和最小编码范围内，就直接跳过，这样应该可以节省解压缩的时间和减少数据返回。
但这个没有试过，不知实际效果如何。而且很多时候词典内容都带有HTML标记(不是Compat的情况)，这样子意义就不大。
我主要有两个顾虑：
1）生成索引可能会让数据库文件变得很大
2）那个sqlite的全文检索功能估计在压缩模式下用不了。
不会很大，我上面提到过，全文索引的体积是 mdx 的 1.25 倍左右，不同 mdx 有不同数据。
SQLite 全文索引可以只存储索引，不存储数据。即索引只是引导搜索到数据表的 id，仅此而已，你的数据表该压缩就压缩。
当然了，时间换空间似乎也是一种解决方法，但是现在存储空间也不是很贵。
2 Likes
对线需要的水平略高，插不上嘴。
侧重时间还是空间，用这种还是用那种，可以作个统一的入口API和出口API解耦啊，只要输入和输出是准确的，方法可以不同，实现用各自偏好的实现，答案是多解，没有题目要求说只能留一个解吧。
所以对于家里有矿的来说，可以直接选择不压缩 
好！一定要加上这个选项！ 
我看坛里，需要全文搜索的可能需要重新结构化例句的中文翻译。
像我只需要搜索英文例句的发音。
所以后续可以按不同需要开发专用的数据结构进行搜索，不是所有数据都要全文范围内的所有文字“搜索”的，可能只是在某些结构中才搜索。现在用全文搜索，也是在妥协。妥协的更爽、更快一点当然更好啦！
我解压了下常用的LDOCE5的mdx，从224M到876M，4倍；MDD从1.2G到1.3G，不到10倍的变化，不压缩也行啊。
因为也不是所有的词典都要全文检索，仅仅是众多词典中的其中的几个词典中的某几个结构中搜索一些词汇，GoldenDict不知道怎么设置指定词典才开启全文搜索。
如果是不涉及全文检索的存储压缩，那只要平常搜索时像GoldenDict或手机各个词典APP，也没有大差太慢的，不影响的时候能压多小压多小呗。
而拥有庞大的词典库的用户可能会有明显的观感，对空间和时间都会有些担心，那时可以优化下词典格式本身，到底哪个地方拖慢了速度。
而最后，我是没什么贡献，所以神仙们喜欢开发成什么样的，我就用什么样的，有比没有强嘛，已经很感谢各位了。 
2 Likes