good point.

eager_group 确实很好用，但存在一些问题：

1. eager_group 好像不支持 Rails 5，好像也不维护了，这个帖子提的方案不依赖任何 gem，不存在维护问题
2. 这个帖子的方案无论有多少个需要聚合的指标，都只产生一条 SQL，而 eager group 如果有 n 个指标，需要产生 n+1 个 SQL
3. eager_group 只是 aggregate_function(aggregate_column)，算是一种最经典的形式，但现实需求往往比这要复杂，很多 case 处理不来。

1.这里有各个版本的特性支持：https://www.postgresql.org/about/featurematrix/

3.主要是可以利用其它 scope relation 等组合，raw SQL 复用困难。。

关于是不是全表扫的问题，感觉好多人对这个有误解，可能是之前的“避免 subquery”之类文章看多了吧...

过程化语言，已经指定好了需要执行的每一个步骤。

但 SQL 是描述性语言，只指定了做什么，而没有指定怎么做。

至于如何做更有效率，这取决于优化器，所以有着更多的可能。

同一条 SQL 在不同 DB 上执行，由于优化器的实现、执行计划的不同、数据量和分布的不同、索引的不同、内存等资源的不同，产生的执行计划完全不一样。

所以不要轻易说一条 SQL 是不是全表扫描...

是不是全表要看执行计划，你 explian 一下咯

不需要哇

mysql 是一直不行啊 mysql8 相当于 pg8 的水平吧 不过现在 pg 都出 11 了…

问一下 gitlab ci 可以脱离 gitlab 使用吗

因为 mysql 不好用啊

@ceclinux-github

就是批量处理和离线处理。

最简单的就是实时处理，有变化就实时计算一次相关的分数矩阵，这样并发情况会消耗太多资源。批量处理就是说，架构上，对于增量数据可以做成延时和定时的，比如新增变化的 item 数量达到 10000 才把新增的相似度矩阵更新，或每天批量跑一次新增的数据。

离线处理是指，如果数据量再大，计算资源成为瓶颈，架构上可以把计算相似度矩阵的工作和主业务抽出来，使用独立的数据库，再通过微服务的方式给主业务。

也可以试试 PredictionIO：https://predictionio.apache.org/start/

tapd 吧

1. Postgres 是一个生态系统，并不单单是 Postgres 数据库，数据库领域和 Map Reduce 匹配的概念是 MPP，上面其实提到过，Greenplum、Citus、Redshift、postgres x 都是可以无缝切换的，包括你上面提到的 timescaledb，其实只是 postgres 的一个扩展而已。从 SQL 的角度，其实上面方案是可以迁移到 Hive 的，如果你认为 Hive 比 Postgres 快。
2. 数据量多大和推荐系统关系其实并不大，海量日志当然可以占很大空间，而实际对业务产生价值的部分并不多，这一般是先 ETL 提取出有价值的数据。
3. Map Reduce 是大数据处理的一个解决方案，并不是唯一方案。
4. SQL 是一个通用接口，现在有哪个大数据工具不支持 SQL 的吗，elasticsearch？kalfka？spark？
5. 任何技术决策都是基于你当前的状况，如果你公司不差钱，当然招一个数据团队来做那当然是很棒啦。如果你是一个小型创业公司，正巧有员工可以用一天时间用 SQL 搭建一个推荐系统，那么不是更好么...

写这个的目的就是想消除一提到推荐系统就认为需要 spark hadoop 之类的大数据工具才能做的观念。你要知道即使是京东那么大的电商网站，SKU 数量 14 年也就 4 千万而已，12 年不过百万。

其实并不是 CTE 就一定比子查询慢，要看场景的，CTE 会物化结果，对于一些重计算的查询是好事，CTE 其实让 Postgres 有了 caching 功能...

https://medium.com/@hakibenita/be-careful-with-cte-in-postgresql-fca5e24d2119

textql -header -sql "select name, group_concat(value) from csv group by name" csv.txt

关注点不同

数据库的 vslidation 是数据完整性约束的最后保障

model 的 validation 是为了错误回显

model 层可以做的更多，但并不是所有类型都可以做完善，比如唯一性，而数据库层面要做的话有些比较复杂，想做的画可以用 Check Constraints

eventmachine

http://www.dpriver.com/pp/sqlformat.htm 这个不错，很多配置选项，但没 API 接口

找了一下用 river 的原因：https://books.google.com/books?id=90c41yKz3IUC&pg=PA37&lpg=PA37&dq=Rivers+and+Vertical+Spacing+sql&source=bl&ots=FfbhSCKOI7&sig=5bfrv5Eza5-VMfXGe-v7W-isDyU&hl=zh-TW&sa=X&ved=2ahUKEwjFqc-ywq7dAhWKf7wKHTdWAPUQ6AEwAnoECAgQAQ#v=onepage&q=Rivers%20and%20Vertical%20Spacing%20sql&f=false

用 river 这种缩进方式写起了麻烦，但读起来更容易，上下左右扫一眼就清楚结构了。

SQL 嵌套结构超过三层确实很难读了，缩进也非常痛苦。一般我会用 CTE 把子查询上移，让层次没那么深。比如：

WITH ss AS (
  SELECT depname, 
         empno, 
         salary, 
         enroll_date,
         rank() OVER (PARTITION BY depname ORDER BY salary DESC, empno) AS pos
     FRO empsalary
)

SELECT depname, 
       empno, 
       salary, 
       enroll_date
  FROM ss
 WHERE pos < 3;

但有时候 WITH 表达式和子查询其实查询计划并不完全等价的，比如下推不能什么的，就要多写一些重复的 WHERE 条件。 编辑器好像不容易自动格式化，只能手动对齐....

举个例子，我遇到的大部分"DRY"是这样的，既然项目后台都是 CRUD，为什么要重复一百遍 CRUD 写后台，那么我们抽出一个可以复用的 RailsAdmin or xxxAdmin 吧，这个抽象呢 80% 时候是非常便利的，写起来非常爽，可是随着需求的变化，RailsAdmin 满足不了需求了，你要钻进 RailsAdmin 的源码去各种 monkeypatch，甚至还是有些地方不那么容易改，这就是过早抽象的代价，就如上面说的：I’d rather make an easy change to 3 files than a hard change to 1 file；CRUD 虽然重复，但其实是容易改的，抽象出一个可以复用的虽然 DRY，但抽象不完美的时候是不容易改的，即便只要改一处。

这个例子举得可能有点跳，但 method 和 class 甚至是服务都是同一个道理。

挺好的，就是 caching 不好做了…

不改就给他们返回 bad request

错觉吧

没有具体业务场景，谈什么合理不合理

典型的反模式，开心就好

这不就是 saas 做 sharding 吗

可以配置忽略一些异常类型

ga 漏斗分析留存分析什么的都可以的…