这是一个创建于 1801 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如我用一个 map 管理了所有对象，这个 map 相当于表，里面是一条条的记录。然后我对各个记录做操作。每个记录还能嵌套对象，就跟表关联一样。因为追求性能，这种做法简直吊打 redis 和 db，并且也有某些数值在并发时不能溢出一个临界值的要求也很好满足。
但是，这种做法一旦系统挂掉数据都没了，所以还得同步保存到 db 。现在关键是不能每次操作都保存吧，那样性能一下就受限了。那么如何搞，定时保存？系统重启还得再都加载到 map 。还是说这种做法从源头来说就不伦不类？
如果单纯从面向对象上来设计一个系统，感觉真的是太清晰了，如果考虑数据库，只能设计成一切操作都是增删改查直接访问数据库？
但是，这种做法一旦系统挂掉数据都没了，所以还得同步保存到 db 。现在关键是不能每次操作都保存吧，那样性能一下就受限了。那么如何搞，定时保存？系统重启还得再都加载到 map 。还是说这种做法从源头来说就不伦不类？
如果单纯从面向对象上来设计一个系统，感觉真的是太清晰了，如果考虑数据库，只能设计成一切操作都是增删改查直接访问数据库？
 | 1 crclz 2020-11-04 21:57:02 +08:00 80 年代的面向对象数据库。https://en.wikipedia.org/wiki/Object_database 纯面向对象的设计方式有很多弱点，包括读写粒度、数据的查询方式…… 所以面向对象数据库只是昙花一现，关系型数据库一直是主流。 只不过在这之间有一种东西，既可以保证部分的基于对象的清晰思维，又可以保证存取粒度合理、查询容易：领域驱动设计（ DDD ）。 |
 | 2 DoctorCat 2020-11-04 23:47:36 +08:00 这就是自己程序实现的 cache 么，这么做谈不上不伦不类但是数据易失性是铁定的。既然考虑到容灾机制，不是写入 db 就是自己将数据写盘，写 db 觉得性能不够，写盘涉及到 IO 性能问题所以还要选择合理的数据结构，map 直接序列化刷到存储中性能开销不算低（相对磁盘的寻道速度 微观上而言）尤其涉及到存储的高可用例如分布式存储系统。 还是涉及个 bucket 结构的数据结构随存随写吧……最后发现自己实现了一套分布式缓存，维护这套玩意投资回报并不高，质疑自己不用 redis 到底是图个啥？只因为当时差几个毫秒？ |
 | 3 aguesuka 2020-11-05 17:55:23 +08:00 via Android 把对 map 的操作写到日志里，重启时从日志里恢复。 kb/s 级别的 io 量应该没问题 |
Select Language