Ridge Arquitetura de tempo de execução

Esta página mapeia o tempo de execução compartilhado por Ridge DB e Ridge Admin. É derivado da corrente ridged, ridge_pgwire, ridge_sql, ridgee ridge-admin implementações em vez de um modelo de banco de dados genérico.

Abra o diagrama Archify interativo

O mapa interativo fornece componentes pesquisáveis, rastreamento de rota direcionado, visualizações guiadas para o caminho de consulta principal, acesso remoto SSH, durabilidade e segurança, dark/light temas, navegação pelo teclado e SVG ou exportação raster.

Mapa do sistema

Browser
  │ HTTP on loopback
  ▼
Ridge Admin security gate
  │ authenticated API + workspace
  ▼
Ridge Admin services ──► four-connection pgwire pool
                              │
                              ├── local pgwire ─────────────────────┐
                              │                                     │
                              └── verified SSH direct-tcpip ────────┤
                                                                    ▼
                                                       ridged pgwire runtime
                                                                    │
                                                                    ▼
                                                       Ridge SQL session
                                                                    │
                                                                    ▼
                                                       Ridge core / MVCC
                                                                    │
                                                                    ▼
                                                       B+Trees + WAL + rows

O caminho principal é intencionalmente estreito. O navegador nunca recebe um soquete de banco de dados ou SSH credencial. Os perfis locais e remotos convergem no mesmo pgwire, SQL contratos de transação e armazenamento.

Componentes de tempo de execução

Fluxo de consulta principal

1. Ridge Admin vincula seu servidor HTTP a 127.0.0.1 e fornece ao navegador uma token de fragmento único.
2. O navegador troca o fragmento por um HTTP-somente cookie de sessão e recebe um token CSRF por sessão.
3. O despachante HTTP valida tamanho da solicitação, rota, método, Host, Origem, sessão, CSRF e tipo de conteúdo antes de invocar um serviço.
4. Um espaço de trabalho SQL aluga uma conexão própria do conjunto de quatro conexões.
5. Perfis locais conectam-se a ridged em loopback. Perfis remotos colocam o mesmo protocolo de cliente por meio de um canal SSH direct-tcpip verificado sem abrir um ouvinte de encaminhamento.
6. Um fragmento do reator ridged valida o protocolo de inicialização, TLS/authentication frames, instruções preparadas, estado do portal, pressão de saída e metadados de cancelamento.
7. O coordenador de armazenamento roteia a solicitação limitada para um Ridge SQL sessão.
8. Ridge SQL analisa e planeja uma instrução suportada, aplica result/work limites e executa através do Ridge núcleo.
9. Ridge núcleo se aplica MVCC visibilidade, bloqueio, restrições, índices, WAL publicação, B+Tree alterações, somas de verificação e fsync conforme necessário.
10. Os resultados retornam através do pgwire. Ridge Admin converte protocolo limitado frames to JSON or CSV and returns them to the browser.

Uma gravação interrompida nunca é reproduzida automaticamente. Ridge Admin marca um resultado ambíguo como incerto e requer verificação do operador.

Modelo de simultaneidade

Persistente ridged requer pelo menos dois trabalhadores Seed. Ele divide parte do conjunto de trabalhadores em fragmentos de reator não bloqueadores e mantém a capacidade para trabalho de armazenamento. Cada fragmento possui seu ouvinte, placa de conexão, estado de protocolo, planos preparados, contrapressão de saída, token de cancelamento e um leitor de instantâneo somente leitura. Canais limitados conectam fragmentos ao coordenador de armazenamento.

O coordenador preserva a propriedade da transação, o agrupamento de commits, o dreno de desligamento e o roteamento de cancelamento. As leituras podem usar instantâneos independentes; gravações duráveis ainda passam Ridge detecção de conflitos e regras de publicação.

Ridge Admin usa spawn estruturado para conexões HTTP limitadas e um gerenciador SSH próprio. O estado do servidor possui o pool, as concessões do espaço de trabalho, o cancelamento de consulta ativa, o estado de reconexão e a limpeza determinística.

Dependências externas

Ridge não depende de um PostgreSQL servidor. PostgreSQL a compatibilidade é limitada ao subconjunto documentado de ligações do lado do cliente.

Limites de segurança

Navegador para Ridge Admin

• O ouvinte é apenas loopback.
• O segredo do lançamento é guardado no URL fragmento, não um parâmetro de consulta.
• A troca única produz um cookie de sessão SameSite somente HTTP.
• As mutações requerem uma origem de loopback exata e um token CSRF por sessão.
• Host, tipo de conteúdo, tamanho header/body e combinações de route/method são validado antes do envio.
• CSP, sem loja, nosniffe o comportamento restritivo do referenciador reduzem o navegador exposição.

Ridge Admin para banco de dados

• O back-end possui todos os soquetes, transações, segredos e limpeza.
• Os perfis não persistem senhas de banco de dados, senhas SSH ou chaves senhas.
• As credenciais retidas para cancelamento ou reconexão são limitadas e zerado da memória do processo.
• Um espaço de trabalho permanece fixado ao seu estado de transação e conexão.
• As desconexões não causam a repetição da consulta.

SSH limite

• A verificação estrita de host conhecido é o padrão; aceitar-novo explícito é um política de primeiro contato, não um desvio de host alterado.
• Nativo direct-tcpip canais alcançam o loopback remoto ridged ponto final.
• Nenhum ouvinte de encaminhamento TCP local está aberto.
• O cancelamento de consulta usa um canal SSH verificado separado.

ridged limite

• O serviço é vinculado apenas a 127.0.0.1.
• TLS e autenticação por senha são configurados pelo operador; um texto não criptografado o desafio de senha é aceito somente dentro de TLS.
• O servidor atual expõe um database/user configurado mais um limitado função somente leitura, não uma PostgreSQL catálogo de funções.
• Mensagens, instruções preparadas, portais, filas, buffers de resultados e contagens de conexões verificaram limites.
• Não compatível SQL e as formas de protocolo falham explicitamente.

Limite de armazenamento

• As raízes do banco de dados e de backup são absolutas e controladas pelo operador.
• Nomes e caminhos rejeitam travessia; restaurar recusa um destino existente.
• WAL quadros e arquivos de backup são verificados.
• A confirmação de confirmação segue o limite de durabilidade documentado.
• A recuperação reproduz o estado comprometido de forma idempotente e reconstrói o estado derivado índices e cabeças.
• A edição direta de arquivos ignora invariantes e não é suportada.

Contenção de falhas

Não objetivos arquitetônicos

Este mapa não implica um multiusuário remoto Ridge Admin serviço, geral PostgreSQL administração, replicação, clustering, fragmentação, ouvinte de banco de dados público, SCRAM, identidades de certificados, completo PostgreSQL catálogos ou irrestritos driver/ORM compatibilidade.

Proveniência do diagrama

O artefato interativo foi produzido com Archify 2.12 no modo Arquitetura usando a apresentação estática Clássica e o portão de composição Showcase. Sua fonte digitada é seed/docs/diagrams/ridge-runtime.architecture.json.

O mapa é apoiado por evidências pela inspeção do repositório, mas intencionalmente não incorpora caminhos de repositórios privados como evidências de origem clicáveis. Os arquivos de origem listados acima permanecem como âncoras de revisão.