用tidb验证价值投资是否真的可行

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
方法如下
把美股的时分数据存入tidb

计算每个股票的roe
把股票收益分成三类 roe大于1 roe大于0 roe<0
然后分别计算每类收益的平均值 看看roe大的股票是否平均收益更高点

2

数据库就是个底层，是基础，上层还有中间件，应用层，网络层等等
貌似和你说的事情有一点点关系，但好像又没有啥关系
如果是计算能力和存储能力的话，HTAP，计算和存储分离的TiDB应该可以满足你的需求

3

你每天每一只股票的分钟数据就是很大的数据量
浙江电力每只电表的数据量一个数据库还存不下 一天就会产生50t数据。数据在我们生活中无处不在。你身边最常吃的肯德基 pg库就100个。当年pg挂了一天整个收银都收不了，损失惨重
和原神联动一下 用户跑去买肯德基
直接收银系统又挂了。
你说要不要用tidb？
这几天王军在帮肯德基招人 你会tidb 可以去试试 月薪过万不是梦。给你个三万五万的 开开心心维护tidb数据库

1 个赞
4

其实我们身边大部分程序叫做数据库应用
就一个数据库。一个应用。甚多公司为了显示自己牛逼。用分布式框架。系统内交互来交互去。kafka一大堆 redis一大堆。 所以带出来中间件。应用层 网络层等一系列问题。发展了arm 链路监控链路追踪等一系列技术。但唯独搞不定一个流量的突发情况。来点高峰流量。业务就挂了。
可以说一顿操作猛如虎。一看业务还是挂。

所以业务是不是就数据库和应用两层会比较好？淘宝单体应用也跑的好好的。你最多因为数据库抗不住上一个kafka做数据的排队写入。如果用tidb数据库。你都可以卡夫卡都不用。让流量持续打入数据库以免redis缓存这种中间件突然崩溃的时候数据库支撑不住。

这个就是tidb cto黄东旭所写文章中提到的持续流量压力。

DynamoDB观察到，级联故障的根本原因之一是：短时间内流量突变，导致流量突变的常见因素之一是缓存故障，尽管我们大多认为缓存命中率越高越好（论文可能提到分区路由器表的缓存命中率约为99.75%），如此高的缓存命中率意味着当缓存失败（或大量新节点加入时的缓存预热阶段）时，元数据服务必须能够携带400次（最坏的情况是，0.25% → 100%）流量激增，DynamoDB通过以下方式解决这个问题：

  1. 在请求路由器和元数据服务中间添加一个级别的分布式内存缓存MemDS。错过请求路由器的本地缓存后，它不会直接访问元服务，而是首先访问MemDS，然后MemDS在后台访问元数据服务以填充数据。通过添加一层缓存进行峰值剃须，这相当于添加另一层保险，这是一种常见的方式。
  2. 第二种方式非常聪明，只是提到了请求路由器实际上通过MemDS获取元数据，当请求没有到达MemDS中的缓存时，很容易理解。但真正聪明的是：即使缓存命中，MemDS也会异步访问元数据服务。原因：1.它确保MemDS中的现有缓存尽快更新2.为元数据服务带来“稳定”流量（尽管它可能更大）
  3. 例如，“稳定”但更大的交通相当于在水中玩耍，这样当洪水来临时，你就可以有良好的信心，:slight_smile:

之所以说大部分应用都是数据库应用，主要有以下几个原因：

  1. 数据存储和管理：应用程序通常需要存储和管理大量的数据，例如用户信息、业务数据、交易记录等。数据库提供了一种有效的方式来组织、存储和管理这些数据。

  2. 数据一致性和完整性：数据库可以确保数据的一致性和完整性，防止数据丢失、重复或不一致。

  3. 高效的数据检索：能够快速地搜索、筛选和提取所需的数据，提高应用程序的性能和响应速度。

  4. 数据共享和协作：多个用户或组件可以同时访问和操作数据库中的数据，促进了团队协作和信息共享。

  5. 数据安全：可以设置用户权限、加密等安全措施，保护数据的安全性和隐私性。

  6. 数据分析和报表：便于生成各种报表和分析，帮助决策者做出明智的决策。

  7. 可靠性和容错性：数据库通常具有备份和恢复功能，以防止数据丢失或损坏。

  8. 可扩展性：可以随着业务的增长和需求的变化进行扩展和升级。

  9. 标准化和规范化：遵循一定的数据库设计原则和规范，有助于提高数据质量和维护性。

  10. 行业标准和成熟技术：数据库技术经过长期的发展和验证，是一种成熟、可靠的技术。
    你去看我们身边大部分应用 不涉及到算法。就是计算了往数据库里存放数据。
    说白了就curd。
    那为啥数据库还经常崩溃呢？

  11. 缺乏经验或知识：开发人员可能对数据库的特性和最佳实践了解不足。

  12. 错误的设计或实现：数据库架构设计不合理，或者代码中存在逻辑错误。

  13. 性能优化不足：没有进行适当的性能优化，导致数据库负载过高。

  14. 大量并发访问：没有处理好高并发情况下的数据库访问。

  15. 异常情况处理不当：对异常情况的处理不够完善，可能导致数据库崩溃。

  16. 缺乏测试：代码没有经过充分的测试，潜在问题没有被发现。

  17. 资源管理不善：例如，没有正确释放数据库连接等资源。

  18. 数据库配置问题：数据库的配置不合适，无法满足应用的需求。

为了避免这些问题，可以采取以下措施：

  1. 加强开发人员的培训和知识积累。
  2. 进行合理的数据库设计和代码实现。
  3. 注重性能优化和并发处理。
  4. 妥善处理异常情况。
  5. 进行充分的测试。
  6. 合理管理资源。
  7. 优化数据库配置。

东旭的原文blog如下
Some notes on DynamoDB 2022 paper - me.0xffff.me 最近都删完了中文。也需要备份了

1 个赞
5

:thinking:这不得搞个机房啊~

1 个赞
6

:+1:

7

必须要机房 几千万在上面呢

8

数据库只是存放数据，至于如何做到各种数据展现就看你前端应用的表现了

9

牛 X 克拉斯

10

牛 :cow:

11

:+1: :+1:

12

学习到了

13

这种和是否用 tidb 没啥关系

14

:+1:学习

15

牛逼 学习了