Skip to content

Commit 7c6ab59

Browse files
committed
take a note about clickhouse
1 parent 5170664 commit 7c6ab59

File tree

2 files changed

+194
-0
lines changed

2 files changed

+194
-0
lines changed

clickhouse/README.md

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
# Clickhouse
2+
3+
## 1. Clickhouse's structure explained
4+
5+
Source: <https://posthog.com/blog/clickhouse-vs-elasticsearch>
6+
7+
ClickHouse is engineered to process data in a massive, consolidated place. Unlike Elasticsearch, ClickHouse’s optimizations don’t happen through distributing data, but by efficiently pre-processing it in anticipation of queries.
8+
9+
There are three major components that enable ClickHouse to return aggregations, such as averages, sums, and standard deviations, in millisecond times over petabytes of data.
10+
11+
### 1.1. Component 1: Columnar layout
12+
13+
ClickHouse’s columnar layout – which flips rows and columns in storage relative to a MySQL database – makes aggregations efficient.
14+
15+
When databases physically access data, they scan data row-by-row. By extension, if an analyst is trying to calculate the average value of bank account balances in a PostgreSQL database, they would need to access every bank account row. Alone, that would probably blow out memory. But in ClickHouse, the same analyst would only need to access one (physical) row of data – the bank balance one – and collapse it into an average.
16+
17+
Again, this is a physical row of data. As far as ClickHouse’s interface goes, data is still stored in a traditional format. ClickHouse’s syntax still treats individual entries as rows and attributes as columns. But under the hood, ClickHouse stores the data in an inverted arrangement, optimized for merging attribute data into single values.
18+
19+
### 1.2. Component 2: Materialized views
20+
21+
ClickHouse’s second superpower is dynamic materialized views.
22+
23+
Materialized views are not a new concept – in MySQL or PostgreSQL, a materialized view is a new table that can be queried from, rendered by a SQL query accessing other tables. However, once new data is added to the core tables, that materialized view goes out-of-date. Because creating materialized views is often expensive in traditional databases given their non-columnar layout, refreshing materialized views can only happen occasionally.
24+
25+
But ClickHouse truly makes materialized views dynamic. ClickHouse doesn’t only accomplish this because of the columnar layout of its data. It also leverages incremental data structures that merges data strategically.
26+
27+
### 1.3. Component 3: Specialized engines
28+
29+
ClickHouse has a series of specialized engines that enable developers to take advantage of multiple CPUs in parallel on the same machine. For instance, there is an engine for summing data (`SummingMergeTree`) and removing duplicates (`ReplacingMergeTree`). This technique has some resemblance to Elasticsearch’s parallelization across multiple machines to expedite search; ClickHouse does it at a more granular, per-machine level.
30+
31+
### 1.4. Sharding
32+
33+
ClickHouse has some overlap with Elasticsearch’s sharding features. ClickHouse extends Apache Zookeeper to manage multiple instances of ClickHouse should data need to be split across machines. However, this concept of sharding is closer to Elasticsearch’s support for multiple clusters – it is more a big data distribution problem, not a smaller optimization for speeding up queries.

web-dev/nextjs/README.md

Lines changed: 161 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,161 @@
1+
# NextJS
2+
3+
## 1. Introduction
4+
5+
## 2. Project structure (nextjs15)
6+
7+
Source:
8+
9+
- <https://nextjs.org/docs/app/getting-started/project-structure>
10+
- <https://www.wisp.blog/blog/the-ultimate-guide-to-organizing-your-nextjs-15-project-structure>
11+
12+
```text
13+
├── src/
14+
│ ├── app/
15+
│ ├── components/
16+
│ ├── lib/
17+
│ ├── utils/
18+
│ └── styles/
19+
├── public/
20+
├── package.json
21+
└── next.config.js
22+
```
23+
24+
### 2.1. Core project structure
25+
26+
- One of the first decisions you'll face is whether to use a `src` directory. While Next.js works perfectly fine without it, using a `src` directory offers several benefits:
27+
- Clear separation between source code and configuration files
28+
- Easier to implement tooling and build processes
29+
- Cleaner root directory
30+
- More consistent with other JavaScript/TypeScript projects
31+
- With Next.js 15's App Router, the `app` directory is where your routing magic happens. Here's how to structure it effectively:
32+
- Files directly in `app` affect the root route.
33+
- Folder create a new routes.
34+
- Parentheses `()` create route groups that don't affect the URL structure
35+
- Colocate non-routable files with folders `_folder`.
36+
- Parameterize segments with square brackets. Use `[segment]` for a single param, `[...segment]` for catch‑all, and `[[...segment]]` for optional catch‑all. Access values via the params prop.
37+
- Special files like `layout.tsx` and `page.tsx` serve specific purposes in the routing system
38+
39+
```text
40+
src/app/
41+
├── layout.tsx
42+
├── page.tsx
43+
├── (auth)/
44+
│ ├── login/
45+
│ └── register/
46+
├── dashboard/
47+
│ ├── layout.tsx
48+
│ ├── page.tsx
49+
│ └── settings/
50+
└── api/
51+
```
52+
53+
### 2.2. Organizing components
54+
55+
The components directory is often the heart of your Next.js application. Here's a proven structure that scales well:
56+
57+
```text
58+
src/components/
59+
├── ui/
60+
│ ├── Button/
61+
│ │ ├── Button.tsx
62+
│ │ ├── Button.test.tsx
63+
│ │ └── index.ts
64+
│ ├── Card/
65+
│ └── Modal/
66+
├── layout/
67+
│ ├── Header/
68+
│ ├── Footer/
69+
│ └── Sidebar/
70+
└── features/
71+
├── auth/
72+
└── dashboard/
73+
```
74+
75+
- The `ui` folder contains your basic building blocks - eusable components that aren't tied to specific business logic. These are your buttons, inputs, cards, and modals.
76+
- Layout components are larger pieces that form your application's structure. They're typically used across multiple pages but might have more specific functionality than UI components.
77+
- Feature components are tied to specific business features or domains. For example, a `LoginForm` component would go in `features/auth/`, while a `DashboardStats` component belongs in `features/dashboard/`.
78+
79+
### 2.3. Managing utilities and libraries
80+
81+
```text
82+
src/
83+
├── utils/
84+
│ ├── formatting.ts
85+
│ ├── validation.ts
86+
│ └── helpers.ts
87+
└── lib/
88+
├── auth.ts
89+
├── api.ts
90+
└── database.ts
91+
```
92+
93+
- The `utils` directory should contain pure utility functions that:
94+
- Have no side effects
95+
- Don't depend on external services
96+
- Can be easily tested in isolation
97+
- Examples include:
98+
- Date formatting functions
99+
- String manipulation helpers
100+
- Calculation utilities
101+
- The `lib` directory is for more complex functionality that often:
102+
- Interfaces with external services
103+
- Contains business logic
104+
- Manages state or side effects
105+
- Common examples include:
106+
- API client configurations
107+
- Authentication helpers
108+
- Database connections
109+
110+
### 2.4. State management and models
111+
112+
When using state management solutions like Zustand, organize your store files logically:
113+
114+
```text
115+
src/
116+
├── store/
117+
│ ├── auth.store.ts
118+
│ ├── user.store.ts
119+
│ └── theme.store.ts
120+
└── models/
121+
├── user.model.ts
122+
└── product.model.ts
123+
```
124+
125+
- Store organization: each store file should:
126+
- Focus on a specific domain
127+
- Export a single store instance
128+
- Include related actions and selectors
129+
- The `models` directory contains TypeScript interfaces and type definitions that are used across your application:
130+
131+
```ts
132+
// user.model.ts
133+
export interface User {
134+
id: string
135+
email: string
136+
name: string
137+
role: "user" | "admin"
138+
}
139+
```
140+
141+
### 2.5. Styling organization
142+
143+
```text
144+
src/
145+
├── styles/
146+
│ ├── global.css
147+
│ ├── variables.css
148+
│ └── themes/
149+
│ ├── light.css
150+
│ └── dark.css
151+
└── components/
152+
└── Button/
153+
├── Button.tsx
154+
└── Button.module.css
155+
```
156+
157+
- Keep global styles, variables, and theme definitions in the `styles` directory.
158+
- For component-specific styles:
159+
- Use CSS Modules alongside component files.
160+
- Name them matching the component (e.g., Button.module.css for Button.tsx).
161+
- Keep them in the same folder as the component.

0 commit comments

Comments
 (0)