你有没有看到我 😂

玩这个是不是还得自己备黄金电缆

经济不好的时候，减少消耗，少折腾。😆 我们是蛰伏。

还好 我就就是柔光砖。就是你别太在意的话就不用那么勤快。但是你想很干净的话，柔光砖的上限很高。

感觉和以前做开发时一样，新接口上线后老接口不敢删除。。。

We have deployed a test relay using this storage. It typically has fewer than 200 online clients, resulting in low load and ample redundant resources. Please feel free to add it to your relay list so I can better improve its performance. Relay address : wss://top.testrelay.top

## Nostr Event Store Version `v0.7.0` Release Log This update includes numerous feature enhancements, performance optimizations, and critical fixes, improving system stability and flexibility. Key updates are as follows: ### Important Features and Functionality - **Enhanced Aggregation Functionality** - Added metadata support for aggregation operations. - Support for multi-index aggregation queries, improving complex query capabilities. - Adjusted the maximum aggregation grouping key logic, improving aggregation efficiency under large data volumes. - Supplemented aggregation-related documentation. - **Replaceable Kind Event Configuration** - Added replaceable kind event configuration to both base-relay and remote-relay, supporting more flexible event replacement and deletion strategies. - **Batch Save and Validation** - Added validation after batch save operations to improve data consistency. - **Delete by Filter** - Added batch delete functionality based on conditions, supporting filtering for duplicate IDs, improving the accuracy and efficiency of deletion operations. ### Query and Index Optimization - **Added time limits to multi-index range construction** to prevent performance bottlenecks in extreme cases. - **Removed the default limit from the query interface**, supporting more flexible query needs. - **Added limits to count queries** to prevent excessive resource consumption. - **Bug fixes related to index rebuilding and refreshing**, including issues such as inconsistent index counts and flush errors. - **Enhanced WAL (Write-Ahead Log)** - Added ID verification to improve log consistency. - Adjusted log format, fixing the bug of only having a single WAL file. ### Other Fixes and Improvements - **Fixed the segment count error in the segment statistics interface**. - **Repaired and improved test cases**. - **Adjusted .gitignore file**. - **Performance and stability improvements**, including minor optimizations such as "fix too many pings". #nostr_event_store --- About nostr_event_store's Aggregation, you can read from here About nostr_event_store's deployment methods, you can read from here

## About `nostr_event_store`'s Aggregation --- ### What is Aggregation? Aggregation is a mechanism for grouping, statistically analyzing, and aggregating event data. It allows you to perform statistical, trend analysis, and ranking operations on events based on different fields (such as author, event type, tags, time, etc.). --- ### What can Aggregation do? - Count the total number of events or the number of groups - Analyze trends by time binning (e.g., daily, hourly) - Group by multiple dimensions such as author, event type, and tags - Query the activity level or distribution under a specific author, tag, or topic --- ### Specific Examples (including parameters and calling methods) #### 1. Count active users and their posts on a specific day ``` q := &types.AggregationQuery{ Filter: &types.QueryFilter{ Since: uint32(dayStart.Unix()), Until: uint32(dayEnd.Unix()) - 1, }, GroupBy: []types.GroupByField{types.GroupByAuthor, types.GroupByKind}, AggFunc: types.AggCount, OrderDesc: true, Limit: 1000, } entries, err := s.client.QueryAggregation(ctx, q) ``` --- #### 2. Statistics on daily event trends ``` q := &types.AggregationQuery{ Filter: &types.QueryFilter{ Since: timeWindow.StartUnix, Until: timeWindow.EndUnix - 1, Kinds: kinds, }, GroupBy: []types.GroupByField{types.GroupByTimeBucket}, AggFunc: types.AggCount, TimeBucketSeconds: 86400, // A day OrderDesc: false, } entries, err := s.client.QueryAggregation(ctx, q) ``` --- #### 3. Statistics on popular tags ``` q := &types.AggregationQuery{ Filter: &types.QueryFilter{ Since: timeWindow.StartUnix, Until: timeWindow.EndUnix - 1, }, GroupBy: []types.GroupByField{types.GroupByTagValue}, AggFunc: types.AggCount, TagName: "t", OrderDesc: true, Limit: 20, } entries, err := s.client.QueryAggregation(ctx, q) ``` --- #### 4. Statistics on the most active authors under a certain topic（KOL） ``` q := &types.AggregationQuery{ Filter: &types.QueryFilter{ Since: timeWindow.StartUnix, Until: timeWindow.EndUnix - 1, Tags: map[string][]string{"t": {"A topic"}}, }, GroupBy: []types.GroupByField{types.GroupByTagValue, types.GroupByAuthor}, AggFunc: types.AggCount, TagName: "t", OrderDesc: true, Limit: 20, } entries, err := s.client.QueryAggregation(ctx, q) ``` --- #### 5. Statistical analysis of author activity trends on a specific topic ``` q := &types.AggregationQuery{ Filter: &types.QueryFilter{ Since: timeWindow.StartUnix, Until: timeWindow.EndUnix - 1, Authors: [][32]byte{pub}, Tags: map[string][]string{"t": {"A topic"}}, }, GroupBy: []types.GroupByField{types.GroupByAuthor, types.GroupByTagValue, types.GroupByTimeBucket}, AggFunc: types.AggCount, TagName: "t", TimeBucketSeconds: 86400, OrderDesc: false, } entries, err := s.client.QueryAggregation(ctx, q) ``` --- These parameters and calling methods can be flexibly combined to meet various statistical and analytical needs. The core is to construct an `AggregationQuery` and then use the `QueryAggregation` method to initiate an aggregation query. --- These are some relay data statistics functions that I developed based on this Aggregation feature. Project link: https://github.com/haorendashu/nostr_event_store #nostr_event_store

`nostr_event_store` supports three main deployment methods, each suitable for different application scenarios: ## 1. Application-integrated (e.g., `demos/base-relay`) - Method: The event store is directly integrated into your Go application process as a library. API calls are direct, requiring no network communication. - Advantages: Extreme performance (no network latency), simple deployment, suitable for single-machine/embedded scenarios, easy to develop and debug. - Disadvantages: Cannot be scaled across multiple processes/machines; the event store is affected when the process crashes, making high availability difficult. ## 2. Remote deployment (e.g., `demos/remote-relay`) - Method: The event store runs as an independent service process, communicating with the application via a gRPC remote interface. - Advantages: Decoupling of the application and the event store; independent scaling, restarting, and monitoring; supports multiple client access; facilitates service-oriented deployment. - Disadvantages: Network communication overhead; slightly higher deployment and maintenance complexity; slightly inferior performance compared to the built-in method in extremely low-latency scenarios. ## 3. Sharded Deployment (Under Development) - Method: Multiple machines/processes, each running one event store instance, sharded by author pubkey hash, with a coordinator responsible for routing and aggregation. - Advantages: Strong horizontal scalability, distributed load across single nodes, suitable for large-scale data and high-concurrency scenarios, limited impact from single shard failures. - Disadvantages: Complex implementation and maintenance (requires coordinator, shard routing, cross-shard query aggregation), more complex consistency and recovery mechanisms, and higher initial deployment costs. ## Summary: - Small projects/single machine: Recommended for application integration, simple and efficient. - Requires decoupling of multiple processes/services: Recommended for remote deployment. - For ultimate scalability and high availability: Recommended for sharded deployment, but requires more development and maintenance resources. Project link: https://github.com/haorendashu/nostr_event_store #nostr_event_store

🤣 我说我和我老婆~~~ 我小孩还是在读小学~~~

估计是对方的 私信收件箱中继 没有找到。话说，这个配置什么时候变成了必要的了~~~

我家那个也是初中开始谈的。 读书的时候，多次被家长和老师撞到。 毕业之后也就自然走到一起了 😅