¿Métodos no SQL para la contabilidad de alta frecuencia?

Question

¿Conoce alguien el estado de la técnica de estructuras de datos no SQL para la contabilidad de alta frecuencia, ya sea del lado del cliente, del corredor o de la bolsa? Estoy pensando específicamente en el problema de registrar los datos de las operaciones individuales en transacciones adecuadas, con débitos y créditos equilibrados. En mi caso, lo haré en un libro de órdenes de límite rápido o directamente junto a él, pero puedo ver otras razones para que exista esta bestia. Y sí, estoy de acuerdo en que ninguno de los actuales motores nosql populares no-ACID son en absoluto adecuados para este trabajo. Estoy asumiendo que voy a tener que escribir esto.

Una respuesta útil a esta pregunta podría ser tan simple como un enlace a un documento sobre el tema de la contabilidad no SQL o nosql en un contexto de comercio de alto volumen -- obviamente estoy usando las combinaciones equivocadas de términos de búsqueda, porque no estoy encontrando mucho todavía.

En lo que estoy trabajando es en un proyecto que incluye un libro de órdenes de límite y una contabilidad en cada nodo de una red o tejido distribuido. En mi caso, los instrumentos negociados podrían describirse mejor como opciones reales o derivados reales, incluyendo algunos exóticos leves. La gran mayoría de las órdenes serían iniciadas por máquinas, y la tasa de datos parece que podría alcanzar fácilmente los 60.000 intercambios/segundo en cada nodo. (Sin entrar en una disertación más larga, podría ayudar a explicar que estoy en Silicon Valley estos días; esto es obviamente para un nuevo mercado, no para uno existente). Véase http://en.wikipedia.org/wiki/Real_options_valuation si no te has encontrado con opciones reales antes.

Respuestas parciales, basadas en parte en las respuestas a esta pregunta hasta ahora:

• Un mecanismo de contabilidad creado a tal efecto sería probablemente estructurado en forma de registro, sólo en forma de apéndice, probablemente utilizando una API no SQL para la velocidad de inserción. El propio motor podría ser una base de datos hipergráfica. Si se ejecuta en múltiples nodos, necesitaría una forma de proporcionar transacciones resumidas a los otros nodos de forma peer-to-peer. Cuanto más indago en esto, más empieza a parecerse a un hipergrafo distribuido.

  • https://mathoverflow.net/questions/13750/what-are-the-applications-of-hypergraphs
  • http://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html

• En el mundo de la HFT, parece que el procedimiento estándar sigue siendo: Registrar pero no indexar las operaciones, hacer aritmética simple ignorando los débitos y créditos, y luego sintetizar periódicamente las transacciones resumidas y equilibradas al RDBMS contable. Ejecutar MTM en lote. ¿Hay algo que alguien pueda decir sobre cómo que se hacen "simples matemáticas y registros locales"? Sé cómo lo hacíamos en el mundo de los derivados hace 15 años, pero francamente tanto éste como MTM eran lentos y feos, e implicaban servidores NFS, archivos planos y scripts de shell. Tiene nada ¿cambió? ;-)

• De acuerdo, al eliminar "contabilidad" de los términos de búsqueda acabo de encontrar esto - una pregunta diferente a primera vista, que cubre tanto los datos financieros como los de las garrapatas, pero vale la pena leerlo - parece que tenía algunas de las mismas ideas: Uso del almacenamiento NoSQL en finanzas

  • Parece que valdría la pena repetir mis búsquedas en google, citeseer, etc., sustituyendo "finanzas" por "contabilidad".

• El Procesamiento de Eventos Complejos (CEP) trata de resolver algunos de los mismos problemas -- se me ocurrió que incluir el CEP en las mismas búsquedas podría ser fructífero. Lo primero que encontré fue este artículo (escéptico, pero con humor) en el que se habla de la lentitud con la que se ha adoptado el CEP y de la exageración del nosql: http://www.hftreview.com/pg/blog/darkstar/read/32333/whats-wrong-with-complex-event-processing

Answer 1

Sé que esta es probablemente una respuesta ingenua, pero cuando empecé a hacer análisis de datos para el comercio personal busqué algo mucho más rápido que SQL. Programo en C++ y encontré que HDF5 era la respuesta a todos mis problemas

http://www.hdfgroup.org/HDF5/

No está orientado a la contabilidad, pero lo bueno es que puedes hacer casi cualquier cosa con él y es muy rápido. Aunque tiene un poco de curva de aprendizaje

Answer 2

Tengo que pensar que hay un montón de propósitos especiales muy rápidos y optimizados de propósito especial muy rápidos y optimizados.

Sí y no. No creo que tengas un volumen alto en absoluto, simplemente tienes un servidor de nivel corporativo para la base de datos, no un hosting barato de gama baja. Yo hago unas 2000 transacciones por segundo en un SQL Server con una base de datos de gama media.

El núcleo será:

• Desacoplar el frente y la espalda con una cola de mensajes de todos modos.
• Tomar las ejecuciones de las operaciones desde un enlace de backoffice FIX que informa desde la compensación/corredor.

parece un enorme desperdicio de potencia del centro de datos cuando un propósito más moderno construido, probablemente un motor de contabilidad no SQL, podría ser órdenes de magnitud más rápido.

Hay una cosa que falla: SQL tiene integridad de datos, mientras que NoSql se escribe a menudo ignorando los requisitos de integridad de datos. La falta de integridad de los datos se puede evitar en muchas cosas, pero no en la contabilidad.

También echas de menos que la contabilidad sea una parte estandarizada de los productos básicos. Las grandes empresas manejan algo como SAP, y quieren que todos sus datos estén ahí, sin importar los costos. No es una pérdida de tiempo actualizar el único sistema central que hace la nómina, todas las facturas de la organización, etc. además de la contabilidad comercial.

También es una cuestión de si la contabilidad realmente necesita cada operación - el back office sí, para consolidar y comprobar, pero la contabilidad está bien con los resúmenes equilibrados sintetizados. Hasta ahora no hago muchas operaciones, pero envío los totales mensuales de la PNL con el estado de cuenta del corredor a mi contador (donde va directamente a mis cálculos mensuales de ganancias/pérdidas e impuestos). Nunca haré algo diferente, incluso cuando el volumen se dispare - pero consolidaré diariamente o cada hora y correlacionaré INTERNAMENTE, pero no para la contabilidad.