亚洲色成人网站www永久,亚洲欧美人成视频一区在线,亚洲国产成人高清在线观看,亚洲精品久久久久久动漫,亚洲国产精品久久电影欧美

現(xiàn)有一張成績(jī)表, 主鍵是用戶 id, 如何根據(jù)用戶 id 查詢?cè)撚脩粼诒碇惺欠衽旁谇?100 名以及上榜后的名次

另外,水平分表后,filter 要從多張表查詢,不僅增加了查詢次數(shù),還要對(duì)結(jié)果進(jìn)行合并。性能上是否可取？

還是會(huì)異常焦慮。每個(gè)月花一兩千買點(diǎn)喜歡的東西維持下自己的快樂算不算奢侈？ 所以買不買 Edge 530 ？

Spring data MongoTemplate.可以做到按字段值的一部分分組聚合嗎？ 類似關(guān)系型數(shù)據(jù)庫 sql(postgres)如下： SELECT "left"(code,2) As "code",SUM(a) AS a FROM t GROUP BY "left"(code,2). 手機(jī)打的格式可能會(huì)亂

大佬們好,我用的 mongodb4.2,目前數(shù)據(jù)導(dǎo)入進(jìn)去了,80 億數(shù)據(jù),導(dǎo)了很久。。然后在建聯(lián)合唯一索引的時(shí)候,有數(shù)據(jù)重復(fù),報(bào)錯(cuò)無法創(chuàng)建。。。
有沒有什么好的方法可以建聯(lián)合唯一索引,刪了數(shù)據(jù)先建索引再重新導(dǎo),實(shí)在太折騰太慢了。。。

同樣的數(shù)據(jù),使用 mongo 自帶命令 mongoinsert 導(dǎo)入,速度很快,每秒 15000 條左右,60 億數(shù)據(jù)占空間 300G 。 我手寫的代碼,使用 pymongo 的 insert_one 方法插入同樣的數(shù)據(jù),速度很慢,每秒 300 條左右,因?yàn)橐鶕?jù)數(shù)據(jù)插入不同的集合,所以只能使用 insert_one 。 而且插入后的數(shù)據(jù),占空間很大,60 億占 2T 空間。
找了很多原因,不知道性能和空間占用為什么差這么大,都使用的默認(rèn) snappy 壓縮。如果說性能是 insert_one 導(dǎo)致的,那一樣的數(shù)據(jù)量一樣的數(shù)據(jù),占空間為什么差距這么大。。（ PS.mongoinsert 導(dǎo)入一個(gè)集合,我的程序?qū)胫?有幾千個(gè)集合。不知道這個(gè)有沒有原因）
希望大佬們給些建議,感謝感謝?。?

大佬們,我數(shù)據(jù)量一共 60 億,現(xiàn)在插入了 6 億左右,一開始的時(shí)候 每次 insert_many 只需要 0.05 秒 1000 條
目前已經(jīng)插入 6 億左右,現(xiàn)在 1000 條數(shù)據(jù)有時(shí)候需要 20 秒,非常的慢。
用什么辦法可以調(diào)優(yōu)一下呢？
mongo 是單點(diǎn)的,部署在一臺(tái)機(jī)器上,沒有分片和副本。
試過 bulk_write 性能是一樣的

網(wǎng)上的說法都是擴(kuò)大 linux 的文件打開數(shù),這個(gè)方式有點(diǎn)不適合我。
插入的數(shù)據(jù)量比較大,根據(jù)數(shù)據(jù)特點(diǎn)我去創(chuàng)建不同的集合存儲(chǔ),就導(dǎo)致有非常多的集合,所以文件打開數(shù)會(huì)特別大。
這個(gè)打開數(shù)是和什么有關(guān)系的？為什么我插入成功的數(shù)據(jù),沒有釋放掉打開數(shù)呢？應(yīng)該怎么操作？

我本身有 200G 的文本數(shù)據(jù),每一條是一個(gè) json,我需要把這個(gè) json 二次處理一下再插進(jìn)去,處理之后文本稍微大了那么一丟丟,_id 字段我也重新定義了,長(zhǎng)度大約 32 位。 只做了這樣的操作,為什么導(dǎo)入 mongo 之后,占用的空間還是 200G 呢？完全沒壓縮。。我的前綴和文檔壓縮也配置了。。。用的 pymongo insert_many 插入的,而且速度極慢,10 秒才能插入 3000 條。
如果我直接用 mongoimport 命令導(dǎo)入數(shù)據(jù),實(shí)際占用空間只有 20G 。速度每秒一萬五千條。 速度和壓縮率和我使用 pymongo 相比差距很大,我也單獨(dú)打印了我代碼里數(shù)據(jù)處理時(shí)間,數(shù)據(jù)處理的時(shí)間大約 100 毫秒,幾乎可以不計(jì),耗時(shí)最大的就是執(zhí)行 insert_many 的時(shí)候。
為什么差距會(huì)這么大呢？

請(qǐng)教一下在電商項(xiàng)目有較多子類目的話, 這個(gè)類目表通常是怎么設(shè)計(jì)的?
比如說一個(gè)分類如下: 運(yùn)動(dòng) -> 運(yùn)動(dòng)鞋 -> 足球鞋, 讓一雙足球鞋能在客戶點(diǎn)擊這三種類目時(shí)都能展示出來, 那這個(gè)商品和分類的關(guān)系該怎么設(shè)計(jì)?
比如說京東這種 list.html?cat=101,201,301 ,難道這三個(gè)對(duì)應(yīng) id 就設(shè)計(jì)成 '101', '101,201', '101,201,301', 比如查詢第二個(gè)就看字段是否包含 '101,201' 了事了?

比如 group = {'_id':'$uid','num':{'$push':'$num'}} aggregate([match, group])
這樣生成的結(jié)果,num 是一個(gè)列表 /數(shù)組。
如果我希望 num 結(jié)果是一個(gè){date:num,...}的字典,應(yīng)該用什么命令？

大佬們,mongodb 可以在配置指定集合的默認(rèn)壓縮方式嗎
因?yàn)槲沂歉鶕?jù)數(shù)據(jù) 動(dòng)態(tài)創(chuàng)建集合的,集合很多 幾千幾萬個(gè),不能每次判斷是否存在然后根據(jù)創(chuàng)建的代碼去創(chuàng)建,效率太低了。但是數(shù)據(jù)需要壓縮,有啥辦法指定 mongo 的默認(rèn)壓縮嗎？就是動(dòng)態(tài)創(chuàng)建集合的時(shí)候,自動(dòng)就壓縮了。
snappy+前綴壓縮那種的。
目前版本是 mongodb 4.2

比如我搜索"耐克 籃球鞋", 如何查找同時(shí)包含這兩個(gè)詞的結(jié)果?
看到的例子中:
{$text: {$search: "耐克 籃球鞋"} 多了些不符合的
{$text: {$search: "\"耐克 籃球鞋\""} 有漏網(wǎng)之魚
還是通過其他方式實(shí)現(xiàn)?

這篇文章獻(xiàn)給正為 MongoDB 磁盤占用率偏高而憂心忡忡的運(yùn)維。:)
文章鏈接
https://nanmu.me/zh-cn/posts/2020/a-practical-guide-to-reclaim-disk-space-from-mongo-db/
公眾號(hào)：nanmu42
摘要 如何定位大庫和大表？ 如何科學(xué)地 compact ？ 如何科學(xué)地刪除陳舊數(shù)據(jù)？
希望各位喜歡,歡迎留言交流。

我有一個(gè)擁有五百萬個(gè)文檔的集合,文檔的結(jié)構(gòu)如下： { "_id" : ObjectId("5ed23bd292845eaf1e488965"), "categoryId" : 18790, "targetType" : 43, "targetId" : 433, "priority" : 0 }
集合擁有索引 categoryId_1_priority_-1 。
我期望如下的 Aggregation Pipeline 使用到索引,但是事實(shí)上并沒有。 db.collection.aggregate([{$facet: {"category_1_order_by_priority_limit_2": [{$match: {categoryId: 1}}, {$sort: {priority: -1}}, {$limit: 2}],"category_2_order_by_priority_limit_3": [{$match: {categoryId: 2}}, {$sort: {priority: -1}}, {$limit: 3}]}}])
explain 的結(jié)果如下： { "stages" : [ { "$cursor" : { "query" : { }, "queryPlanner" : { "plannerVersion" : 1, "namespace" : "test.collection", "indexFilterSet" : false, "parsedQuery" : { }, "queryHash" : "8B3D4AB8", "planCacheKey" : "8B3D4AB8", "winningPlan" : { "stage" : "COLLSCAN", "direction" : "forward" }, "rejectedPlans" : [ ] } } }, { "$facet" : { ... } } ], "serverInfo" : { ... }, "ok" : 1 }
我應(yīng)該怎么做才能使用到索引呢？
indexing - MongoDB Aggregation Pipeline $match $sort doesn't use index - Stack Overflow

mongo 查詢語句 db.t_policy.find({ $or: [{$and:[{"policy_no": "31809341900153386520"}]}, {"bill_date": "", "effective_date": "", "engine_no": "", "expire_date": "", "first_register_date": "", "license_plate_no": "", "model": "", "vin": ""}] })
搜索條件某些字段有,某些字段可能沒得,是建立單個(gè)索引,還是建議集合的索引,集合索引是不是有時(shí)命中不到呀。如果不建索引 cpu 猛升。沒有這方面經(jīng)驗(yàn)問問大家！

https://docs.djangoproject.com/en/3.1/releases/3.1/
沒看到有人發(fā),我來發(fā)一下好了 新增 view 和 middleware 的異步支持,可以在 view 上用 async def 了。ORM 的異步支持接下來的版本會(huì)繼續(xù)做 JSONField 已經(jīng)支持所有的數(shù)據(jù)庫,用 MySQL 的想要這個(gè)特性可以不再需要 Django-MySQL 了
Django 毫無疑問是最好的 Python Web 框架,開發(fā)團(tuán)隊(duì)也是相當(dāng)孜孜不倦…

現(xiàn)在想用 django 寫一個(gè) web,用哪個(gè)版本比較好一些。之前接觸過,1.x 的?，F(xiàn)在我看都更新到 3.x 了

環(huán)境是 springboot2.0,連接池是 springboot 帶的 lettuce 配置使用的是默認(rèn)配置 現(xiàn)象就是 一段時(shí)間不是用 redis, 再去使用的時(shí)候就會(huì)報(bào) command timeout exception
下面是報(bào)錯(cuò)信息 Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException: Command timed out at org.springframework.data.redis.connection.lettuce.LettuceExceptionConverter.convert(LettuceExceptionConverter.java:70) at org.springframework.data.redis.connection.lettuce.LettuceExceptionConverter.convert(LettuceExceptionConverter.java:41) at org.springframework.data.redis.PassThroughExceptionTranslationStrategy.translate(PassThroughExceptionTranslationStrategy.java:44) at org.springframework.data.redis.FallbackExceptionTranslationStrategy.translate(FallbackExceptionTranslationStrategy.java:42) at org.springframework.data.redis.connection.lettuce.LettuceConnection.convertLettuceAccessException(LettuceConnection.java:257) at org.springframework.data.redis.connection.lettuce.LettuceKeyCommands.convertLettuceAccessException(LettuceKeyCommands.java:650) at org.springframework.data.redis.connection.lettuce.LettuceKeyCommands.keys(LettuceKeyCommands.java:148) at org.springframework.data.redis.connection.DefaultedRedisConnection.keys(DefaultedRedisConnection.java:75) at org.springframework.data.redis.core.RedisTemplate.lambda$keys$10(RedisTemplate.java:840) at org.springframework.data.redis.core.RedisTemplate.execute(RedisTemplate.java:224) at org.springframework.data.redis.core.RedisTemplate.execute(RedisTemplate.java:184) at org.springframework.data.redis.core.RedisTemplate.keys(RedisTemplate.java:840)
早網(wǎng)上找了找沒找到什么有用的解決方案,特來請(qǐng)教

Redis 的高可用方案有兩種,哨兵和集群。
個(gè)人淺薄理解,哨兵模式就是創(chuàng)建一個(gè)備胎,備胎同步 master 數(shù)據(jù),在 master 出現(xiàn)異常的時(shí)候進(jìn)行切換。
而集群則是創(chuàng)建一個(gè) slave,slave 同步 master 數(shù)據(jù),可用于客戶端讀取,在 master 出現(xiàn)異常的時(shí)候進(jìn)行選舉切換為 master 。集群模式要求最少 3 個(gè) master 節(jié)點(diǎn),master 節(jié)點(diǎn)間分槽管理數(shù)據(jù)。
在正常情況下,哨兵就是個(gè)吃白飯的,沒有任何作用,而集群的 slave 則參與讀操作。
怎么看都是集群完勝啊,為啥還有人在堅(jiān)持維護(hù)哨兵模式呢(比如 helm 的 redis-ha)？

1.本地 windows 起了個(gè) 相同的代碼,相同數(shù)據(jù),就能全存進(jìn)去,部署的服務(wù)器上 就怎么都對(duì)不上數(shù)。 2.此 redis 還有其他項(xiàng)目在用,但代碼層面,可以排除影響。 3.每次都是 4520 4.配置里沒設(shè)最大值限制 5.以前沒出現(xiàn)過類似情況,這套代碼部署過好多個(gè)服務(wù)器 6.KEY 絕對(duì)沒有重復(fù),這個(gè)反復(fù)驗(yàn)證過了 7.沒看到哪報(bào)錯(cuò)了 …… w(?Д?)w~~~~~ w(?Д?)w~~~ w(?Д?)w

在 Distributed locks with Redis – Redis 中,首先它描述了如何正確地使用單實(shí)例實(shí)現(xiàn)分布式鎖,然后它介紹了分布式版本的算法。但是對(duì)于分布式版本,我有許多疑問。
首先,那篇文章說 In the distributed version of the algorithm we assume we have N Redis masters. Those nodes are totally independent, so we don’t use replication or any other implicit coordination system. We already described how to acquire and release the lock safely in a single instance. We take for granted that the algorithm will use this method to acquire and release the lock in a single instance. In our examples we set N=5, which is a reasonable value, so we need to run 5 Redis masters on different computers or virtual machines in order to ensure that they’ll fail in a mostly independent way. In order to acquire the lock, the client performs the following operations: It gets the current time in milliseconds. It tries to acquire the lock in all the N instances sequentially, using the same key name and random value in all the instances. During step 2, when setting the lock in each instance, the client uses a timeout which is small compared to the total lock auto-release time in order to acquire it. For example if the auto-release time is 10 seconds, the timeout could be in the ~ 5-50 milliseconds range. This prevents the client from remaining blocked for a long time trying to talk with a Redis node which is down: if an instance is not available, we should try to talk with the next instance ASAP. The client computes how much time elapsed in order to acquire the lock, by subtracting from the current time the timestamp obtained in step 1. If and only if the client was able to acquire the lock in the majority of the instances (at least 3), and the total time elapsed to acquire the lock is less than lock validity time, the lock is considered to be acquired. If the lock was acquired, its validity time is considered to be the initial validity time minus the time elapsed, as computed in step 3. If the client failed to acquire the lock for some reason (either it was not able to lock N/2+1 instances or the validity time is negative), it will try to unlock all the instances (even the instances it believed it was not able to lock).
我的疑問 為什么要順序地嘗試獲取所有實(shí)例里的鎖呢？同時(shí)嘗試獲取會(huì)存在什么問題呢？ Redlock 算法所說的 auto-release time 是類似于 Distributed locks with Redis – Redis - Correct implementation with a single instance 中所說的 SET resource_name my_random_value NX PX {ttl} 中的 ttl 嗎？也就是我下面所說的 TTL,是嗎？ 在第二步時(shí),會(huì)嘗試在所有實(shí)例中獲取鎖,它所做的行為跟單實(shí)例所做的行為是一樣的,也就是 SET resource_name my_random_value NX PX {ttl} ,那么 ttl 是怎么計(jì)算出來的呢？我認(rèn)為不同實(shí)例的 ttl 是不同的,因?yàn)閲L試獲取在不同的實(shí)例里的鎖的時(shí)間是不一樣的。因?yàn)橐_?！叭绻袑?shí)例的同一個(gè) key 都在同一時(shí)間被刪除”,所以我覺得每個(gè)實(shí)例里所設(shè)置的 ttl 是“ TTL - (在某個(gè)實(shí)例嘗試獲取鎖的時(shí)間 - 第一步獲取到的時(shí)間) ”,對(duì)嗎？（這里的 TTL 表示的是邏輯上的 TTL,并不是真實(shí)設(shè)置在某個(gè)實(shí)例里的 ttl,也就是所有實(shí)例里的同一個(gè) key 都會(huì)在“第一步獲取到的時(shí)間 + TTL”這個(gè)時(shí)間被刪除）

其實(shí)我心里大概是有一個(gè)答案的,就是怕斷電丟 5 分鐘左右的數(shù)據(jù)？
如果不考慮斷電的情況呢,因?yàn)榘⒗镌乞v訊云我用了好多年都沒遇到過斷電,而且就丟失 5 分鐘,概率上還沒有中勒索病毒大。
其他的我暫時(shí)也想不到什么壞處,頂多是邏輯要自己寫,大表拆分起來要?jiǎng)觿?dòng)腦。
好處不用說了,速度起飛,內(nèi)存占用低。
所以還是想請(qǐng)教一下各位大佬,到底有沒有可行性

、、、 [email?protected] :/home/ubuntu/redis-4.0.11# ps -ef | grep -i redis root 23189 1 0 12:05 ? 00:00:00 redis-server *:6379 root 23249 22790 0 12:05 pts/5 00:00:00 grep --color=auto -i redis
[email?protected] :/home/ubuntu/redis-4.0.11# kill 23189 [email?protected] :/home/ubuntu/redis-4.0.11# cd src
[email?protected] :/home/ubuntu/redis-4.0.11/src# redis-server ../redis.conf 23297:C 15 Jun 12:05:52.164 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 23297:C 15 Jun 12:05:52.164 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=23297, just started 23297:C 15 Jun 12:05:52.164 # Configuration loaded [email?protected] :/home/ubuntu/redis-4.0.11/src# 、、、

自從最新的自行編譯版不能使用 SSH 通道以后,一直在使用去年版的,最近看官網(wǎng),發(fā)現(xiàn)上架了 Win10 商店了
看了一下中國(guó)區(qū)的價(jià)格還挺不錯(cuò)的,只要 50 塊錢,對(duì)于我這種有三臺(tái)電腦的來說也很方便,不需要自己去更新了,也不會(huì)有自行編譯版本的各種 GUI 問題。
看介紹反正沒說是不是訂閱制,就當(dāng)他永久的。

PS: 發(fā)現(xiàn)這玩意竟然還有 iPadOS 版本,要占領(lǐng)地球？

用戶姓名 出生日期 性別什么的 k v 存 redis 。
想一次性全部取出來不行嗎 還是 scan ？

需求：
這是昨天面試中遇到的一個(gè)問題,當(dāng)用戶 x 秒內(nèi)請(qǐng)求 y 次,禁止用戶訪問
先寫一些我自己想的方案,下面的 windowStart 為 x 秒之前的 timestamp, current 為現(xiàn)在的 timestamp, threshold 為請(qǐng)求次數(shù)限制。下列方法都需要設(shè)置和更新 key 過期時(shí)間,以免造成 key 泄漏。
方案 1:
用 Redis 的 List 數(shù)據(jù)結(jié)構(gòu)記錄用戶訪問的時(shí)間
當(dāng)用戶訪問時(shí) rpush 當(dāng)前時(shí)間戳并刪掉左側(cè) x 秒之前的時(shí)間戳,此時(shí)該列表的長(zhǎng)度為 x 秒請(qǐng)求次數(shù),注意此方法的 timestamp 需要用 Redis 的 Lua 腳本否則可能因?yàn)楦鳈C(jī)器時(shí)間不同出問題（例如某臺(tái)機(jī)器時(shí)間為未來,則 ltrim 不到該條數(shù)據(jù)后面的正常時(shí)間戳）
偽代碼： redis.rpush(key, current); redis.expire(key, current + y); counter = 0; while (redis.get(key, 0) < windowStart) { counter++; } redis.ltrim(0, counter); if (redis.llen(key) > y) { doBanUser(); }
方案 1 的問題：
只需要最多存 y 條數(shù)據(jù),但是這里用到了 List,Redis 中的 List 為雙向鏈表,每個(gè)節(jié)點(diǎn)包含兩個(gè)指針,在 64 位機(jī)器上占用 128bit,而實(shí)際有用的時(shí)間戳只要 64bit 。迭代鏈表時(shí)會(huì)更慢一些。
方案 2:
使用數(shù)組 ringbuffer 代替方案一的鏈表。
方案 2 的問題：
需要自己開發(fā) Redis module,開發(fā)和運(yùn)維成本較高。另外方案 1 和方案 2 中均存不方便重試和測(cè)試的問題。例如其他業(yè)務(wù)調(diào)自己服務(wù)但是自己服務(wù)超時(shí),此時(shí)業(yè)務(wù)方重試,這種情況不應(yīng)該算用戶訪問了兩次。
方案 3:
使用 Redis 的 ZSet 數(shù)據(jù)結(jié)構(gòu)
以用戶請(qǐng)求的唯一 requestId 為 member,當(dāng)前時(shí)間為 score,如果 requestId 已存在（ logn 復(fù)雜度),不進(jìn)行任何操作,如果不存在,則 ZADD,然后使用 ZRANGEBYSCORE 查看該時(shí)間段內(nèi)請(qǐng)求數(shù)量。該方案同時(shí)需要使用 ZREMRANGEBYSCORE 來刪除過老的元素,我認(rèn)為可以每次或 N 次請(qǐng)求的時(shí)候刪除,面試官說有更好的刪除時(shí)機(jī),但是我也沒有問,這個(gè)問題就這么過去了。
想問問 V 友該方法應(yīng)該如何刪除,或者有沒有更好的方法來用 Redis 限制用戶行為頻率？

開了 VPN, 已確認(rèn) 配置沒問題,打的包在服務(wù)器上運(yùn)行也可以,就是本地 DEBUG 不行。是不是 idea 有特殊端口 vpn 沒開？

問題點(diǎn)：Redis 啟動(dòng)出現(xiàn)兩個(gè) Warning 。 一個(gè) TCP backlog setting of 511 somaxconn value of 128; 一個(gè)是要求 vm.overcommit_memory=1;
修復(fù)嘗試：我按照網(wǎng)上的方法,在 sysctl.conf 文件中新增了 net.core.somaxconn 和 vm.overcommit_memory, 但只有 vm.overcommit_memory 起效果了,而且一旦重啟電腦又會(huì)重現(xiàn)錯(cuò)誤,并未像網(wǎng)上那樣永久解決。 運(yùn)行 sysctl -a 命令顯示 net.core.somaxconn 的值一直是 128 。
錯(cuò)誤起因：NET 項(xiàng)目,最近加了 SignalR,前端小程序用了 Websocket 與后端建立實(shí)時(shí)通信。
目的：reids 啟動(dòng)不再出現(xiàn)這兩個(gè)錯(cuò)誤。
PS：中午再回復(fù)

《 redis 》設(shè)計(jì)與實(shí)現(xiàn) 218 頁,15.7.3”檢測(cè)命令丟失“
”但這條命令卻因?yàn)榫W(wǎng)絡(luò)故障而在傳播的過程中丟失,那么主從服務(wù)器之間的復(fù)制偏移量就會(huì)出現(xiàn)不一致“
主從之間是 tcp 連接,已經(jīng)保證了可靠傳輸,為什么還要考慮”命令丟失“？

大佬們,目前我在刪除一些 mongo 的數(shù)據(jù),根據(jù) ObjectID 刪除,每一次刪除 2000 條。
使用 python 腳本 pymongo delete_many
但是性能上很差,每秒刪除在幾十到幾百條數(shù)據(jù)。
我看內(nèi)存、磁盤、cpu 的壓力都非常小。。不知道問題到底出在哪了。。有什么好辦法可以提高刪除的效率嗎？
不是軟刪除,是真正按數(shù)據(jù)刪掉。

索引會(huì)影響排序的速度嗎？
比如以下 pymongo 代碼 DB['todo'].find({'time': {'$lte': start}}).sort([('lv', 1), ('time', 1)]
排序的邏輯是 lv 小數(shù)字優(yōu)先,lv 同級(jí)時(shí) time 小的優(yōu)先。
對(duì)應(yīng)的查詢目前是建兩個(gè)索引 一個(gè)是 {time:1} 。 另一個(gè)是單獨(dú) {lv:1} 好,還是組合 {lv:1,time:1} 好（還是順序應(yīng)該反過來？）
索引會(huì)影響 aggregate 中 group 的效率嗎？
比如 aggregate 中有一環(huán)是 group group = {'$group':{ '_id': '$main_key', 'key1': {'$max':'$key1'}, 'key2': {'$push':'$key2'}, ... }}
這里面如果對(duì) main_key , key1 , key2 ,... 做索引的話會(huì)提高效率嗎？

1.每天的數(shù)據(jù)量很大,大概 5 億多條,如果用 mysql 存儲(chǔ),再用來查詢監(jiān)控,肯定不行的。 那么用什么來存儲(chǔ)呢？
2.數(shù)據(jù)監(jiān)控報(bào)警,可以知道當(dāng)前金幣發(fā)放的數(shù)據(jù)量,如果超過 /少于 3 天前,7 天前的數(shù)據(jù)量 10%,就發(fā)出報(bào)警, 用什么開源的工具可以快速實(shí)現(xiàn)呢？

docker + 網(wǎng)絡(luò)配置 + nginx 轉(zhuǎn)發(fā) + grafana 監(jiān)控 + harbor 鏡像倉(cāng)庫的搭建 整體的方案及部署文檔,可以做的聯(lián)系我(vx:MTg3NTgwNjM4NTA=),后端部署： （ php 、node 、go 項(xiàng)目） 前端主要部署一些靜態(tài)頁面項(xiàng)目

之前運(yùn)維架構(gòu)基于傳統(tǒng)的虛擬云主機(jī)和其他 IaaS 之上的,傳統(tǒng)云主機(jī)運(yùn)維的可以通過堡壘機(jī)保證操作都記錄下來,滿足等保要求。如果運(yùn)維架構(gòu)遷移到 K8S 上之后應(yīng)該怎樣滿足等保合規(guī)的要求？

老哥們,作為程序員,業(yè)務(wù)晚上會(huì)報(bào)警,自己一個(gè)人還好,影響家里人休息,大家咋處理的。

前情
在疫情期間自己學(xué)習(xí)了 React 開發(fā)了一個(gè) AWS 中國(guó)器的計(jì)算器 https://v2ex.com/t/679030 , 當(dāng)時(shí)核心的動(dòng)機(jī)是 解決日常工作中使用 AWS 中國(guó)區(qū)中成本相關(guān)的問題 React 練手
更新
在 V2 上多次看到前端和后端同學(xué)關(guān)于 React/Vue 的積極討論, 作為一個(gè)背鍋工程師, 反正大家寫什么都需要運(yùn)維, 就都學(xué)習(xí)一下, 這樣也能和前端同學(xué)友好交流. 所有就有了這個(gè) 基于 Vue 的 flashcard 項(xiàng)目.
https://flashcards.engineerdraft.com/cost
此次動(dòng)機(jī) Vue 練手, 只是學(xué)習(xí)沒有應(yīng)用沒有啥意思 希望可以通過 flashcards 的題目來引導(dǎo)大家使用 計(jì)算器 , 來找到答案.
當(dāng)然我也準(zhǔn)備了 容器 和 DNS 相關(guān)的題目, 后續(xù)也會(huì)更新一些小題目來幫助

最近在兩臺(tái)服務(wù)器上線了一個(gè)程序,相同的 cpu,都是 centos7,都沒有 cpufreq governor,但是一個(gè)用 perf stat 抓到的 cycles 只能達(dá)到基準(zhǔn)頻率,而另外一遍能達(dá)到最高的睿頻,兩臺(tái)機(jī)器都比較空閑,可以認(rèn)為還有大量閑置資源,閑置有點(diǎn)不大理解為什么會(huì)有這樣的區(qū)別。
為了說明問題,用服務(wù)器 1 代替有問題的,服務(wù)器 2 代替正常運(yùn)行的。
為了排除 cpu 遷移的問題,在服務(wù)器 1 上添加了 cpu binding,結(jié)果基本沒差別,為了排除 io 的差異,用 tmpfs 直接接管了服務(wù)器 1 的 io 操作,現(xiàn)在服務(wù)器 1 用 perf 抓仍然跑在基頻,不知道有同學(xué)有相關(guān)經(jīng)驗(yàn)沒,求教。
非常感謝。

有啥免費(fèi)好用的 linux 運(yùn)維管理工具推薦呢？ 除了 ansible,SaltStack,Puppet 這些。
輕量級(jí)的,支持批量執(zhí)行 sh,py,sql 腳本, 批量上傳文件,支持主機(jī)、服務(wù)分組管理這些,
功能不需要多,簡(jiǎn)單,穩(wěn)定,安全可靠就好。

最近關(guān)于個(gè)人服務(wù)器的運(yùn)維和管理,寫了一系列文章,可供參考： https://github.com/shfshanyue/op-note
目前,有一個(gè)簡(jiǎn)單的站點(diǎn)部署在上邊 https://shici.xiange.tech