@@ -13,6 +13,8 @@
由于该方案着重于极致的吞吐性能和极低的磁盘占用，而对数据全程进行了压缩。故并不适合于需要es关键字模糊查询的场景使用，而仅支持提前设定好的索引字段查询。数据库使用的是clickhouse集群，配置中心采用的etcd，如果之前没有相关经验的，还涉及了新技术的学习成本，以及需要对部分源码进行改造，故未必适合大部分项目使用。建议关注实现方案和处理超大量级的数据、缓冲、入库等代码逻辑即可，整套思路可适用于多种场景。
+该项目适用于日志量极大，且用于节省中转环节如使用kafka等mq进行日志中转的场景。在京东、方舟健客等公司线上使用，由于各公司日志查询时索引字段不同，固必然有一定的开发工作，需要注意。这不是一个开箱即用的项目。
+
关于性能及机器配置简述，目前线上的worker配置主要为8核32g的docker，32g内存是专门定制的参数，因为worker需要靠纯内存来承接和缓冲大量接收的日志，这样的单机每秒可以承接的日志量为160M-200M，因为是压缩后的，对应原始日志约1个G，约1千万行。
clickhouse机器配置为16核64G内存，单机每秒可以稳定写入180M，再高会丢可用率。对应原始日志约1个G。
weifengwu