lxdlam 最近的时间轴更新 lxdlam 最近的时间轴更新 |
lxdlamStay hungry, stay foolish V2EX 第 91515 号会员，加入于 2015-01-13 12:44:59 +08:00 |
blog.lxdlam.com
北京海淀
lxdlam
lxdlam
lxdlam
lxdlam 最近回复了
2 天前 回复了 lucasj 创建的主题 › 程序员 › 推荐几个你一直在用的开源项目工具 |
DuckDB ，非常好用的 in memory OLAP 数据库，跟 sqlite 一样，而且可以统一连接 csv 、parquet 、mysql 、postgres 数据源，python 包可以兼容 pandas/polars/arrow ，纯粹开箱即用，非常方便
18 天前 回复了 Mianmiss 创建的主题 › 程序员 › 是否应该把程序日志写入到 Mysql 数据库中 |
@lxdlam 没写完发出去了。补充一下特性第一条：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑可以读写分离的架构，使用一些缓存、分片的技术难度会大幅下降，且能在合理资源量内得到一个不错的效果。
18 天前 回复了 Mianmiss 创建的主题 › 程序员 › 是否应该把程序日志写入到 Mysql 数据库中 |
日志需要持久化，尤其是有跨天 case 的可能性。使用 MySQL 或者其他 OLTP DB 是一种方案，但是不是最好的方案。
将日志当作事件流，思考日志的使用场景：
- 问题定位：最常见的 case ，通过请求、用户、设备等等维度抽取一个特定的事件流分析，哪一步出现了问题，这种 case 通常需要对一些特定的 field 当作 key ，抽取查询相关联的事件。
- 数据分析：通过对特定事件进行聚合，计算出来一些业务或者技术指标，诸如平均响应时间、订单完成延迟等。这种场景一定程度上会被 metric 所替代，但是在错误日志聚合上仍然有价值。
同时，日志有一些自己的特性：
- Append only：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑
- 丢失冗余：根据日志量的关系，其实允许一定程度的日志丢失和冗余，也就是没有严格事务要求。
- 量级和查询需求：很多日志都是大海捞针，允许一定的查询延迟和一定延长的运行时间
从上面的角度，其实使用一个 OLAP 系统或者更加专门的系统更好。OLAP 常规的选型可以选择诸如 ELK 、ClickHouse 这样的系统，搭配 Kafka 之类将日志落进去；而比较完善的日志系统现在比较流行的就是 Loki + Promtail/Grafana Agent ；如果量小，使用 fluentd 采集并发送到 S3 使用一些脚本去分析也是 OK 的。
将日志当作事件流，思考日志的使用场景：
- 问题定位：最常见的 case ，通过请求、用户、设备等等维度抽取一个特定的事件流分析，哪一步出现了问题，这种 case 通常需要对一些特定的 field 当作 key ，抽取查询相关联的事件。
- 数据分析：通过对特定事件进行聚合，计算出来一些业务或者技术指标，诸如平均响应时间、订单完成延迟等。这种场景一定程度上会被 metric 所替代，但是在错误日志聚合上仍然有价值。
同时，日志有一些自己的特性：
- Append only：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑
- 丢失冗余：根据日志量的关系，其实允许一定程度的日志丢失和冗余，也就是没有严格事务要求。
- 量级和查询需求：很多日志都是大海捞针，允许一定的查询延迟和一定延长的运行时间
从上面的角度，其实使用一个 OLAP 系统或者更加专门的系统更好。OLAP 常规的选型可以选择诸如 ELK 、ClickHouse 这样的系统，搭配 Kafka 之类将日志落进去；而比较完善的日志系统现在比较流行的就是 Loki + Promtail/Grafana Agent ；如果量小，使用 fluentd 采集并发送到 S3 使用一些脚本去分析也是 OK 的。
23 天前 回复了 UncleCAT4 创建的主题 › Linux › 谈谈使用 Linux 三年以来的感受 |
本科阶段用了很久的 Manjaro ，现在主力开发两台机器还是 macOS + Fedora ，不太追求 Cutting Edge 的滚动更新，Fedora 用着正好。
之前用过一段时间 NixOS ，但是 NixOS 会有一些 dirty hack 的工作要做，会有一定量级的时间定期调配置文件，后面就放弃日常使用了，下一步打算在 CI 场景用一下。
之前用过一段时间 NixOS ，但是 NixOS 会有一些 dirty hack 的工作要做，会有一定量级的时间定期调配置文件，后面就放弃日常使用了，下一步打算在 CI 场景用一下。
30 天前 回复了 Yadomin 创建的主题 › 程序员 › Redis 更换了开源协议 |
Redis 这次换其实是比较强盗逻辑的。
背景是 Redis 之前开发了很多附加组件，如时序数据扩展 Timeseries ，JSON 扩展 RedisJSON ，然后这一系列扩展统称为 Redis Stack ，所有 RedisStack 就是按 SSPL 分发的，同时保持原有的代码为 3-Clause BSD 。
> In fact, more than 50% of redis.io downloads – from Redis 6 and beyond – come from Redis Stack. We now believe that extending this licensing to Redis itself will enable us to continue to evolve the most holistic set of data models, processing engines, and developer capabilities for our users.
根据原文，他们觉得既然有超过 50% 的用户下载 Redis 都是从 Redis Stack 过来的，那为什么不把这俩合一呢？是否合理、怎么合并暂且不提，单纯因为这个原因把 core Redis 的 License 换成 RSAL+SSPL ，就纯粹是在绑架那一批完全用不到 Redis Stack 的用户了。而显然，这虽然看起来是 Redis 跟托管云的斗争，但是实际上这部分成本总会以各种形式转嫁到 end user 上。
背景是 Redis 之前开发了很多附加组件，如时序数据扩展 Timeseries ，JSON 扩展 RedisJSON ，然后这一系列扩展统称为 Redis Stack ，所有 RedisStack 就是按 SSPL 分发的，同时保持原有的代码为 3-Clause BSD 。
> In fact, more than 50% of redis.io downloads – from Redis 6 and beyond – come from Redis Stack. We now believe that extending this licensing to Redis itself will enable us to continue to evolve the most holistic set of data models, processing engines, and developer capabilities for our users.
根据原文，他们觉得既然有超过 50% 的用户下载 Redis 都是从 Redis Stack 过来的，那为什么不把这俩合一呢？是否合理、怎么合并暂且不提，单纯因为这个原因把 core Redis 的 License 换成 RSAL+SSPL ，就纯粹是在绑架那一批完全用不到 Redis Stack 的用户了。而显然，这虽然看起来是 Redis 跟托管云的斗争，但是实际上这部分成本总会以各种形式转嫁到 end user 上。
31 天前 回复了 isAK47 创建的主题 › MacBook Pro › 被苹果 MBP 16 寸的音质震撼到了，有没有类似这种音质的小音箱，或者这种喇叭哪里可以买到？ |
我的桌面是 Windows ，用一对 PreSouns Eris 3.5 ，但是接了个外置声卡走的平衡输出。
31 天前 回复了 xinbaoCode 创建的主题 › 程序员 › 如何简单 100%安全存放自己的密码？ |
33 天前 回复了 zaizaizai2333 创建的主题 › Linux › 原来 Linux 代码也有公司利益、政治斗争。 |
介绍一下另一种形式，并非由一个 committee 来决定的形式：[终身仁慈独裁者]( https://en.wikipedia.org/wiki/Benevolent_dictator_for_life)，从 Python 之父开始的一个特定名称，被他毙掉的 PEP 不计其数。一个非常著名的提案是 PEP-572 ，就是 Python 3.8 引入的赋值（海象）操作符 `:=`，社区对这个提案一直比较两极化，但是 Guido 下场了，最终通过这个提案。
Disclaimer：我并没有说这个提案通过跟 Guido 下场有直接关系，现象如此，而且我也经常使用海象操作符。
Disclaimer：我并没有说这个提案通过跟 Guido 下场有直接关系，现象如此，而且我也经常使用海象操作符。
Select Language